My Intelligent-Product-Documentation project answers questions over uploaded documentation using a stronger pipeline than traditional chunk-and-search RAG.
My project’s traditional RAG baseline is Document -> fixed chunks -> embeddings -> vector search -> LLM.
My fuller pipeline is Document -> parsing/OCR/enrichment -> structure-aware chunks -> embeddings -> hybrid retrieval -> reranking -> context expansion -> compression -> LLM -> validation -> trace logging.
The additional engineering in my project is intended to improve answer quality, debugging, and system reliability.
My ingestion sequence is Document -> Parse -> OCR/Table/Image Enrichment -> Structure-Aware Chunking -> Metadata + Relationship Mapping -> Embeddings -> ChromaDB.
My retrieval sequence is User Query -> Query Transformation -> Hybrid Search -> Rerank -> Context Expansion -> Compression -> LLM -> Validation.
My retrieval pipeline uses query rewriting and expansion.
I expose POST /jobs/{job_id}/retry to retry an ingestion job.
I expose GET /traces/summary/documents for document trace summaries.
I expose GET /traces/summary/retrieval for retrieval trace summaries.
My frontend provides background ingestion job awareness.
My frontend provides query-trace summary metrics.
My frontend provides visibility into top retrieved sources.
My evaluation runner includes sample documentation QA prompts.
My evaluation runner provides automatic pass-rate and citation/context metrics.
My evaluation runner supports trace-aware evaluation over the real backend.
My evaluation dataset format can be strengthened with document-specific expectations.
For stronger document-specific metrics, I can enrich my evaluation set with expected source terms and required answer terms for my own content.
My Docker Compose setup serves the backend at http://localhost:8000.
My Docker Compose setup serves the frontend at http://localhost:3000.
My API documentation is available at http://localhost:8000/docs.
python -m venv venv
pip install -r requirements.txt
copy .env.example .env
python -m uvicorn src.api.main:app --reload --host <redacted> --port 8000
My evaluation covers advanced RAG pipeline behavior.
My project includes trace logging and summaries.
My backend project structure includes FastAPI routes, dependencies, middleware, and models.
My backend project structure includes user authentication services and repositories.
My backend project structure includes parsing, OCR, image and table extraction, and chunking.
My backend project structure includes a background ingestion job service.
My backend project structure includes query trace and evaluation summary services.
My RAG project structure includes a retriever, generator, validator, memory, and compression.
My frontend project structure includes chat, layout, upload, and UI components.
My frontend includes TypeScript interfaces aligned with the API.
My project documentation includes an optional product walkthrough and demo notes.
My evaluation documentation explains how to use the starter evaluation set.
One proposed improvement is per-document retrieval success tracking.
One proposed improvement is moving background ingestion to dedicated workers.
One proposed improvement is storing uploaded artifacts in object storage.
One proposed improvement is adding benchmark snapshots across multiple LLM providers.
I also maintain Intelligent-Product-Documentation, an advanced product-documentation RAG system. It extends fixed-chunk-and-vector-search approaches with document enrichment, structure-aware retrieval, answer validation, and operational visibility.
My Intelligent-Product-Documentation repository is a Python repo on @rashmeetchhabra12's GitHub, started 2026-05 and last updated 2026-07.
I built Intelligent Product Documentation Assistant as an advanced RAG system for product documentation focused on engineering quality, retrieval quality, and operational visibility rather than a thin chatbot demo.
My ingestion pipeline supports PDF, HTML, Markdown, DOCX, and TXT support.
I use OCR fallback for low-text pages.
My document processing includes table-aware extraction paths and image caption enrichment paths.
I use semantic chunking instead of only fixed windows.
My retrieval pipeline combines dense vector search with BM25-style keyword search through hybrid score fusion and cross-encoder reranking.
I expand retrieved context using linked elements, shared parents, same-section context, and adjacent chunks, then use prompt-budget-aware context compression.
My system includes background upload jobs, retry failed jobs, an idempotent upload API, an indexed document registry, and query traces with validation status.
My trace summaries cover pass/fallback counts, average context size, common validation issues, top retrieved documents, and retrieval score summaries.
My frontend is a workspace UI, not just a testing shell.
The workspace exposes uploads, chat-based querying, indexed-document status, ingestion-job awareness, trace metrics, retrieved sources, and retrieval observability. The backend also provides document and job management, query and session handling, authentication, and trace-summary APIs.
I include a lightweight evaluation runner so I can show measurable quality rather than only a working demo.
My bundled sample set is generic by design.
For stronger document-specific evaluation, I can add expected source terms and required answer terms for my own content. The captured project description supplies no benchmark scores, measured pass rates, latency figures, or other numerical evaluation results.
python evaluation/run_eval.py --dataset evaluation/sample_eval_set.json --base-url http://localhost:8000 --output evaluation/latest_report.json
docker compose up --build
pytest tests -v
The Docker Compose setup exposes the backend at http://localhost:8000, the frontend at http://localhost:3000, and API documentation at http://localhost:8000/docs. I can also run the backend and frontend locally using the repository's documented Python virtual-environment, Uvicorn, and npm commands. The backend's supplied local-start command has a redacted host argument.
I document model, retrieval, ingestion, and storage/operations configuration in .env.example. The named settings include MODEL_TYPE, GEMINI_API_KEY, OPENAI_API_KEY, OLLAMA_BASE_URL, TOP_K_RETRIEVAL, TOP_N_RERANK, HYBRID_ALPHA, MAX_EXPANSION_CHUNKS, OCR_ENABLED, IMAGE_CAPTIONING_ENABLED, MAX_IMAGES_PER_PAGE, AUTH_DB_PATH, JOBS_DB_PATH, TRACES_DB_PATH, and UPLOADS_DIR.
The project is organized around FastAPI API code, authentication, document processing, ingestion jobs, observability, RAG, vector storage, and configuration; its frontend contains the API client, components, Zustand state, and TypeScript interfaces. The docs directory has an optional demo walkthrough, and evaluation contains its README and sample set.
My proposed next improvements include add deeper trace drill-down in the frontend.
Other proposed improvements are per-document retrieval success tracking, dedicated workers for background ingestion, object storage for uploaded artifacts, and benchmark snapshots across multiple LLM providers. Their priority and implementation plans are open questions.
I maintain air-hockey-ol, a TypeScript repository on @rashmeetchhabra12's GitHub; started 2026-08, last updated 2026-09.
I built air-hockey-ol as a real-time multiplayer air hockey game using client-side prediction, server reconciliation, rollback, snapshot interpolation, and deterministic simulation.
In air-hockey-ol, two players connect over WebSockets to an authoritative server that simulates the game at 60 Hz; snapshots broadcast at roughly 20 Hz.
My air-hockey-ol browser demo is at https://air-hockey-ol.rashmeetsingh1012.workers.dev and lets players run matches, adjust latency, toggle prediction, switch puck strategies, and overlay authoritative positions.
My simulation uses a fixed 60 Hz step shared by client and server; no I/O, wall-clock reads, or unseeded randomness; same initial state and inputs yield same result.
I use swept collision detection because the puck speed ceiling 30 units per tick against an 18-unit radius; swept detection prevents tunnelling.
My client reconciliation adopts server state, discards acknowledged inputs, and replays the rest; it blends corrections over ~110 ms and snaps large corrections.
My local paddle prediction excludes the opponent, while remote entities render about 100 ms in the past.
I draw paddles from the same source as the puck—prediction or snapshots—to keep collision participants temporally consistent.
My puck strategies trade off responsiveness, smoothness, and accuracy: B favours accuracy, A favours smooth interpolation, and C switches between prediction and interpolation based on ownership.
Puck ownership is derived from authoritative state and computed the same way on both sides; clients never claim the puck; centre-line hysteresis prevents rapid flips.
My server buffers inputs and stamps them with their simulated tick; late inputs cause server rewind, insertion, and replay.
My server's rewind window is 15 ticks (250 ms); inputs older than that are dropped.
Rewinding slightly increases corrections because clients may have reconciled against an earlier snapshot; the intended input tick is nevertheless honoured.
I use a measured client lead of 3 ticks as the middle ground between late inputs and a long prediction horizon.
My collision solver resolves simultaneous strikes by time of impact, with ties broken by slot index.
My production binary codec omits field names, quantises to 16-bit fixed point instead of float64, and uses a bitmask for changed field groups.
Reliable transport means no keyframe recovery path; measured correction error is 0.0 under both codecs.
My seeded virtual-clock harness simulates RTT, jitter, packet loss, datagram-style or TCP-like delivery; production networking uses WebSockets.
My bot runs the real simulation forward for wall bounces and post ricochets; it acts on a few-ticks-old view with seeded, difficulty-scaled error.
My package structure is: sim deterministic simulation; protocol wire format, codecs, transport seam; netcode prediction, reconciliation, interpolation, session; server authoritative room, fixed-timestep loop, rollback; worker Cloudflare Durable Object adapter; client browser rendering; bot scripted opponent; harness headless network benchmarks.
I measure on-screen paddle error against a zero-latency local game in rink units; the rink is 1000 × 600 and the paddle is 34 across.
My paddle-error results are RTT 0 ms: off p50/p99 12.4/187.1, on 0.0/0.0; 100 ms: off 15.8/201.5, on 0.0/0.0; 200 ms: off 3.7/291.2, on 0.0/3.6; 300 ms: off 336.1/336.6, on 0.0/33.8.
My delta-encoded binary protocol reduced measured bandwidth by approximately 88% under recorded benchmark scenarios compared with the JSON baseline; this is not a general property of binary encoding.
My bandwidth results are clean 100 ms: JSON down 7.80 KiB/s, binary down 0.95 KiB/s, JSON up 5.56 KiB/s, binary up 0.63 KiB/s, reduction 88%; 200 ms + 50 ms jitter: JSON down 7.90 KiB/s, binary down 0.99 KiB/s, JSON up 5.62 KiB/s, binary up 0.63 KiB/s, reduction 88%.
My one-way p99 delivery latency under packet loss is: at 1% loss datagram 70 ms and TCP-like 181 ms; at 5% loss 70 ms and 189 ms; at 10% loss 70 ms and 445 ms.
My server sustained 59.99 Hz over 30 s with no catch-up clamping; clean-link reconciliation error was 0.00 units; a late rewound input produced the same final state as a never-late input.
My README reports 235 tests covering simulation and physics, protocol and both codecs, authoritative room and rollback, netcode, bot, and harness.
I use npm run measure to regenerate measurements; the harness runs production code paths as an integration test.
For local development, I install dependencies with npm install, start the client using npm run dev:client, and open http://localhost:5173. The page hosts its own room, simulated network, and both clients, so bot matches need no server; Play vs human requires the worker, started with npm run dev:server on :8787 (wrangler).
My deployment uses a single Cloudflare Worker to serve the built client and host one Durable Object room per match, with page and WebSocket sharing an origin.
I keep a separate I/O-free simulation shared by client, server, bot, and harness; netcode has no DOM, socket, or clock except those handed to it.
My documented design trade-offs are that quantisation costs exact state reconstruction, rollback costs extra corrections, and reliable transport costs head-of-line blocking.
I present the relational schema as a direct mapping from the current in-memory implementation to a production setup.
When I create a sale, I ensure the user's wallet exists.
I allow reconciliation only to approved or rejected states.
For an approved sale in the example, earning 40 with advance 4 gives a final adjustment of 36.
I expose the reconciliation aggregate as final_settlement_total.
My wallet balance may be higher than the final settlement total because advance payouts are credited before reconciliation.
I run a lightweight HTTP API using Python's standard library.
My GET /health endpoint is a simple health check.
I block a duplicate withdrawal request using idempotency_key.
I reject withdrawals within 24 hours of the prior withdrawal.
If a second callback conflicts with a withdrawal's already-terminal state, I reject it.
I handle a rejected sale after an advance payout as a clawback adjustment.
I chose Python because it keeps the domain logic concise and easy to read.
I chose in-memory repositories to keep setup simple and make business rules the main focus.
I allow negative wallet balances to keep rejected-sale clawback handling straightforward.
SQLite or PostgreSQL are alternatives for better persistence and transactional safety.
If the product disallows negative wallet balances, separate debt tracking is an alternative.
My tests cover duplicate payout status updates and duplicate failed-callback idempotency.
My tests check that summary serialization is JSON-safe.
I can run the tests with python -m unittest discover -s tests -v.
I can run the demo with python -m app.demo.
For Windows setup, I install Python 3.11 or newer from python.org.
During Windows installation, I enable Add python.exe to PATH.
If the py launcher works but python does not, I can run tests with py -m unittest discover -s tests -v.
I can create an optional virtual environment with python -m venv .venv.
If python opens the Microsoft Store, I disable the Python App Execution Alias in Windows settings.
If the terminal still cannot find Python, I reopen the terminal after installation.
If both python and py fail, I reinstall Python and ensure PATH was enabled.
For my sample scenario, I repeat the sale-creation request three times.
My sample sale request uses Content-Type: application/json and a body with john_doe, brand_1, and earning 40.
In the sample flow, I run POST /jobs/advance-payouts before reconciling the sales.
I fetch the sample wallet summary with GET /users/john_doe/wallet.
My possible production improvements include replacing in-memory repositories with database-backed repositories.
I could add a payout provider abstraction as a production improvement.
I could add authentication and authorization as production improvements.
I could maintain payout status transition history as a production improvement.
I could add retry handling around external payout operations as a production improvement.
My proposed sales schema is summarized as: sale_id varchar PK; user_id and brand indexed; earning; status pending/approved/rejected; advance_paid default false; advance_paid_amount default 0; finalized default false; timestamps; indexes (status, advance_paid) and (user_id, status).
My proposed wallet schema is summarized as: user_id unique user id; withdrawable_balance current balance; last_withdrawal_at cooldown tracking.
My proposed payout schema is summarized as: payout_id unique payout id; sale_id nullable for withdrawals; amount payout amount; payout_type advance/final/withdrawal/recovery; status initiated/success/failed/rejected/cancelled; idempotency_key retry protection and unique; indexes (user_id, payout_type, status) and (sale_id, payout_type).
My proposed ledger schema is summarized as: entry_id unique ledger id; sale_id; payout_id; signed amount; entry_type domain event type; note audit note.
My payout system's class design is: Sale, UserWallet, Payout, LedgerEntry; SaleRepository, WalletRepository, PayoutRepository, LedgerRepository; SaleService, AdvancePayoutService, ReconciliationService, WithdrawalService, LedgerService, PayoutSystem.
My advance workflow is: pending sales with advance_paid false receive 10% advance payouts; mark sale advance-paid, credit wallet, write ledger entry; advance_paid marker enforces idempotency.
My reconciliation rules are: one reconciliation per sale; approved adjustment earning minus advance_paid_amount; rejected adjustment minus advance_paid_amount; only approved and rejected states.
My example final settlement is: rejected sale earning 40 advance 4 adjustment -4; two approved sales earning 40 advance 4 adjustment 36 each; total 68; aggregate final_settlement_total.
My withdrawal rules are: validate amount and idempotency key; enforce 24-hour rule; check balance; create initiated payout; deduct immediately; write ledger entry.
My withdrawal recovery behavior is: failed, cancelled, or rejected withdrawals restore amount, create recovery payout and ledger entry; duplicate same-terminal-state callbacks idempotent; conflicting terminal callback rejected.
My HTTP API routes are: POST /sales; POST /jobs/advance-payouts; POST /sales/{sale_id}/reconcile; GET /users/{user_id}/wallet; POST /withdrawals; POST /withdrawals/{payout_id}/status; GET /health.
My design trade-offs are: Python for concise readable domain logic; in-memory repositories for simple setup and business-rule focus; negative wallet balances allowed for clawbacks; SQLite or PostgreSQL for persistence and transactional safety; separate debt tracking if negative balances disallowed.
My test coverage includes: advance payout idempotency; reconciliation example and final total; 24-hour withdrawal restriction; failed-withdrawal recovery; duplicate reconciliation; duplicate withdrawal idempotency-key rejection; duplicate status updates and callbacks; JSON-safe summary serialization.
My project files are: app/api.py, app/init.py, app/demo.py, app/enums.py, app/exceptions.py, app/models.py, app/repositories.py, app/serializers.py, app/services.py, tests/test_payout_system.py, .gitignore, main.py, README.md.
My run commands are: python main.py; python -m unittest discover -s tests -v; python -m app.demo.
My Python setup is: standard library only; Windows Python 3.11 or newer; PATH setup; python and py launcher alternatives; optional venv and Windows troubleshooting.
My possible production improvements are: database-backed repositories, transactions, payout provider abstraction, callback authenticity verification, authentication and authorization, status transition history, external-operation retries.
My S2J repository started in 2026-05.
In Skill2Job, I can upload a resume and have it automatically parsed to extract skills, experience, and contact information.
My Skill2Job project uses machine learning to match resumes against available jobs and show similarity scores.
In Skill2Job, clicking “View Details” opens a job detail modal with the full description and a link to apply directly.
Skill2Job lets users view and manage their resume history.
My Skill2Job frontend uses Tailwind CSS for styling.
My Skill2Job frontend uses Lucide React for icons.
My Skill2Job frontend uses Axios for API requests.
My Skill2Job frontend uses React Router for navigation.
My Skill2Job backend uses express-rate-limit for API rate limiting.
My Skill2Job backend entry point is server/index.js.
My Skill2Job Prisma schema is in server/prisma/schema.prisma.
My Skill2Job backend setup guide is in server/README.md.
I use npx prisma migrate dev to run Skill2Job database migrations during development.
I install the Skill2Job ML service dependencies with pip install -r requirements.txt.
For Skill2Job support, the README asks people to open an issue on GitHub.
My Skill2Job project has a React frontend in client/, an Express backend in server/, and a Python ML service in ml-service/.
For job listings, Adzuna API credentials are optional; falls back to Remotive.
My frontend caches job search results in memory for 1 minute; cache is keyed by search query.
My project uses Firebase Authentication with email/password login and registration.
My production services are https://skill2job-server.onrender.com; https://skill2job-ml-service.onrender.com.
My GET /api/jobs endpoint accepts q, location, page, and country; returns combined Adzuna and database jobs.
My GET /api/my-resumes, POST /api/upload-resume, and DELETE /api/resume/:id require x-user-id header.
My POST /api/save-matches endpoint saves job-resume matches to the database.
My project prerequisites are Node.js 16+ and npm; Python 3.8+ with pip; PostgreSQL; Firebase project; optional Adzuna API credentials.
My client environment variables are VITE_FIREBASE_API_KEY, VITE_FIREBASE_AUTH_DOMAIN, VITE_FIREBASE_PROJECT_ID, VITE_FIREBASE_STORAGE_BUCKET, VITE_FIREBASE_MESSAGING_SENDER_ID, VITE_FIREBASE_APP_ID.
My server environment variables are DATABASE_URL, ADZUNA_APP_ID, ADZUNA_API_KEY; example database URL postgresql://user:password@localhost:5432/skill2job.
My setup commands are git clone https://github.com/rashmeetchhabra12/S2J.git; cd Skill2Job; npm install; npm run dev; npx prisma migrate dev; node index.js; pip install -r requirements.txt; python main.py.
My local development URLs are frontend http://localhost:5173; backend http://localhost:5001; ML service http://localhost:8000.
My unchecked future enhancements are email notifications for job matches; advanced filters (salary range, experience level); saved job listings; job application tracking; resume recommendations; mobile app.
pip install -r requirements.txt
uvicorn main:app --reload --host <redacted> --port 8000
My Inverter Load Manager is a JavaScript repository on @rashmeetchhabra12's GitHub; started 2026-09, last updated 2026-09.
I modeled each appliance with OFF, RUNNING, and SHED.
In my model, OFF means the user intentionally turned the appliance off; RUNNING means it is using inverter capacity; SHED means the system temporarily turned it off to make room for a higher-priority appliance.
My frontend treats appliance states as server-owned data and refreshes /api/status after every create, delete, on, or off action.
I keep shed and restore logic in the FastAPI backend, keeping capacity decisions close to the database and avoiding duplicated load rules in the UI.
My backend uses an 800W limit; when turning on an appliance would exceed it, the backend looks for currently running appliances with lower priority and sheds enough of them to fit the requested appliance.
My restore logic runs after an appliance is turned off or deleted, because those actions may free capacity for appliances that were previously shed.
I restore shed appliances in ascending priority order, so the most important waiting loads come back first when capacity allows.
I keep the React UI's plain design: a form, a capacity meter, clear feedback messages, and visually distinct state rows.
With more time, I would add automated backend tests around the edge cases in shed selection and restore ordering, because that logic is the most important part of the app.
To run the app, I start the FastAPI backend from backend by installing its requirements and launching Uvicorn in reload mode on port 8000; the host value in the supplied command is redacted. In a second terminal, I install dependencies and start the React development server from frontend. I open http://localhost:3000; the React app calls http://localhost:8000, so the backend must be running on port 8000.
.\.venv\Scripts\bugrepro.exe investigate `
--target http://<redacted>:8101 `
--report-file examples\live-bug-report.txt `
--expectation-file examples\live-expectation.json `
--model-endpoint https://api.openai.com/v1/chat/completions `
--model "<your-configured-model>"
I refer to the standalone model setup and limitations at setup and limitations.
.\.venv\Scripts\bugrepro.exe investigate `
--decision-backend codex-cli `
--target http://<redacted>:8103 `
--report-file examples\task-bug-report.txt `
--expectation-file examples\task-expectation.json
I refer to Codex setup and limitations at Codex setup and limitations.
.\.venv\Scripts\bugrepro.exe agent serve
When I use an external agent, I give it the local target URL, a bug report or requirements, and supported expectations.
I can consult bugrepro agent --help and bugrepro explore --help for the available commands.
.\.venv\Scripts\bugrepro.exe report --attempt runs\RUN_DIRECTORY --output runs\report.html
I can open the generated report file in a browser.
.\.venv\Scripts\python.exe -m pytest
I require a full OpenAI-compatible Chat Completions endpoint; non-loopback providers require an API key in OPENAI_API_KEY; validated loopback endpoints can run without a key.
For loopback providers that require authentication, a configured key is still sent to loopback providers that require authentication.
My standalone investigation starts and closes its own browser service worker; one validated action per observation; checks the original frozen expectation.
The standalone defaults are 20 actions, 25 model calls, 60-second model I/O timeout.
My complete and error-free attempts include Markdown/portable HTML evidence and a recipe; malformed responses, provider errors and budget exhaustion are investigation errors (exit 2).
Investigation progress is printed to stderr; stdout remains the final JSON result; progress shows decision-call counts, action types and outcomes, and the final check and report path, without prompts or page content.
The bug report, expectation, page observations and action history are sent to the configured provider; use synthetic local test data; keys are read only from the selected environment variable and never recorded.
Windows npm installations resolve their packaged native codex.exe; ReproWitness never runs the npm shell wrapper.
The Codex adapter requests disabled tools and read-only execution, rejects reported tool events, uses a fresh temporary working directory; not a universal no-tools isolation guarantee across CLI versions or managed policies.
My persistent browser service supports starting a session, observing the page, executing validated actions, finishing, and exporting a recipe; browser remains open between commands.
External agents can use local command tools without a provider key in ReproWitness; all investigation paths and prewritten recipes use the same executor; recorded replay follows saved actions without asking an agent to choose them again.
I can create portable HTML reports from saved runs and compare an original attempt with buggy and fixed replays.
My exit codes are: 0 means expectation passed; 1 means it failed; 2 means execution error or inconclusive attempt.
My supported scope is local loopback URLs and Chromium; navigation, click, fill, reload, observation, and screenshots; heading text or exact list item within an accessible region; service workers disabled.
Exploration is limited to three scenarios and sixty actions, including confirmations.
All external browser requests are blocked; default strict policy makes every blocked resource an execution error.
Explicit block-external-images on investigate, run, or replay keeps external images blocked and recorded without making only those image blocks fatal; scripts, frames, navigation, and unrelated errors remain fatal; reports show policy and blocked resources; replay should use same explicit policy.
ReproWitness does not automatically repair application code; a passing scenario covers only the expectation that was tested.
I’m developing ReproWitness, an open-source browser-bug investigation and replay tool. This extends the project history on this page with its documented GitHub identity, current interface, recovery behavior, and Windows installation and quickstart.
I can use ReproWitness’s guided investigation flow with a bundled task app, my own local app, or scripts. The guide has an interactive mode for entering a target and bug report, and a non-interactive JSON mode for scripted use.
For Codex CLI decisions, I check codex --version and codex login status; this backend needs no provider API key.
In the interactive guide, I enter the app URL and a bug report or task, then finish the input with a line containing only ..
I can enter an expectation manually or ask the selected backend to propose one check; I can accept, edit, or reject a proposal, and vague descriptions or unusable proposals offer manual entry.
I review and confirm the complete expectation before investigation starts; it is frozen before browser actions and cannot be changed by the model.
For the bundled demo, the proposal should be a region_text_exact check for region Tasks and text Prepare demo task; I choose 2 to request it, accept with a only if it matches, and confirm freezing with y.
The bundled buggy task fixture intentionally loses the task on reload. If recorded actions add the task and reload without errors, the check should fail with exit code 1; that is the expected demo result, not an installation failure.
Replaying the same recorded check against the buggy fixture should fail it without model calls; replaying the unchanged check against the fixed fixture should pass with exit code 0.
The demo uses port 8103 for the buggy task fixture and port 8104 for the fixed fixture.
The guide ends with an outcome and report path, and prints a PowerShell replay command when export is allowed.
For my own local app, I can start the guide without preparing input files, enter the local URL and bug report or task, and provide a heading or region-item expectation manually or request a proposal.
The non-interactive guide --json mode requires --target, --report-file, --expectation-file, and --decision-backend; it uses the explicit expectation without proposing one. Existing input files and scripts can continue using investigate.
If the model chooses another workflow or an action fails, I should report that actual outcome rather than assume the demo reproduced the bug.
.\.venv\Scripts\bugrepro.exe serve --app tasks --mode buggy --port 8103
.\.venv\Scripts\bugrepro.exe guide --decision-backend codex-cli
.\.venv\Scripts\bugrepro.exe serve --app tasks --mode fixed --port 8104
.\.venv\Scripts\bugrepro.exe replay runs\RUN_DIRECTORY --base-url http://<redacted>:8104
Invoke-Item runs\RUN_DIRECTORY\report.html
The host represented by <redacted> and the exported run directory are not predetermined, so I substitute the appropriate host and the RUN_DIRECTORY printed by the guide. The documented Codex setup is at docs/USAGE.md#codex-cli-decisions; guided setup and limits are at docs/USAGE.md#guided-investigation.
For the demo task, I enter: “Add a task named Prepare demo task. After reloading, it should still appear in the Tasks list.”
I can enter the demo expectation manually by choosing 1, selecting region item with 2, and entering region Tasks and exact text Prepare demo task.
For the Codex CLI backend, endpoint keys stay in environment variables.
After the guide finishes, I inspect the printed HTML report and copy the printed replay command.
ReproWitness is a CLI toolkit for investigating web-app bugs, recording browser evidence, and replaying the same checks after a fix.
I publish ReproWitness as a repo on @rashmeetchhabra12's GitHub; it is HTML, started 2026-10, and was last updated 2026-10.
ReproWitness runs with the bugrepro command; the Python distribution and module remain named bugrepro, and the version remains 0.1.0.
Existing commands, recipes and run formats continue to work without migration.
ReproWitness separates browser execution from agent decisions: a configured model or external agent chooses actions, while the tool validates and executes them, captures observations and screenshots, and checks a fixed expected result.
Saved sequences can be replayed without further model calls.
Observations include button title/tooltip hints and current layout blockers alongside accessible names. These read-only hints help identify icon buttons and offscreen controls; the executor still checks each action.
- I use ReproWitness in four ways: Explore tests user-defined requirements through bounded scenarios and confirms candidate violations by replaying them; Reproduce investigates a reported issue against an expected result supplied before the attempt; Replay runs recorded actions against another local build while preserving the original expectation; Inspect exports HTML reports with screenshots, action details, outcomes, and recipe fingerprints.
Each investigation uses an isolated browser context, and action failures and browser errors are reported separately from failed expectations.
The investigate and guide commands optionally accept --action-recovery-limit 1 or 2; the default is 0 (strict). Only proven pre-dispatch failures can recover. Reports retain failed attempts, exported recipes replay only the successful path with an explicit mapping to source attempt indices, and safety and execution errors remain fatal. The usage guide is docs/USAGE.md#bounded-action-recovery.
I need Python 3.11+ and Chromium installed through Playwright to install ReproWitness.
The documented installation uses Windows PowerShell. I run the commands from the cloned repository root in each terminal and invoke the virtual environment explicitly, so activation is not required.
git clone https://github.com/rashmeetchhabra12/ReproWitness.git
cd ReproWitness
python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e ".[dev]"
.\.venv\Scripts\python.exe -m playwright install chromium
The repository includes an account-switching sample app with buggy and fixed versions, and its quickstart runs a supplied recipe to demonstrate recording and replay.
.\.venv\Scripts\bugrepro.exe serve --mode buggy --port 8101
.\.venv\Scripts\bugrepro.exe serve --mode fixed --port 8102
.\.venv\Scripts\bugrepro.exe run recipes\sample-alice-bob.json --base-url http://<redacted>:8101
The supplied check against the buggy app fails because the previous account's profile remains visible after switching users.
The run command prints a new run directory containing the recipe, structured results, report, and screenshots.
.\.venv\Scripts\bugrepro.exe replay runs\RUN_DIRECTORY --base-url http://<redacted>:8102
When I replay the run against the fixed version, the expectation should now pass; I can add --headed to watch the browser.
My Product Documentation Assistant is an agentic documentation search system using FastAPI, ChromaDB, Sentence Transformers, and LLMs.
My Skill2Job project is an AI-powered job matching platform using Flask, React, PostgreSQL, and NLP-based skill extraction.
My Finance Backend is a production-grade backend with JWT authentication, role-based access control, rate limiting, and PostgreSQL.
My DBP CheckIn project is an Android attendance system with biometric verification, geofencing, and offline-first architecture.
My ShelfAssist project is a cross-platform Kotlin Multiplatform app with ML-powered book recommendations.
My clinic-desk-agent repository was last updated 2026-10.
My Inverter-load-manager repository is listed as JavaScript and was last updated 2026-09.
My S2J repository is listed as TypeScript and was last updated 2026-09.
My air-hockey-ol repository is listed as TypeScript and was last updated 2026-09.
My stock-predict-app repository is listed as Python and was last updated 2025-07.
I have built backend, AI, real-time, and systems projects spanning document question answering, job matching, finance management, inverter-load management, clinic workflows, stock analysis, multiplayer networking, and browser-bug reproduction. These projects gave me practical experience taking ideas through implementation, testing, and release.
My User-Payout-Management repository is a low-level design and Python implementation for a user payout management system for affiliate sales.
My User-Payout-Management repository is on @rashmeetchhabra12's GitHub, uses Python, and started 2026-07 and was last updated 2026-07.
My payout lifecycle starts each sale as pending, pays eligible pending sales a one-time advance payout of 10%, has an admin reconcile each sale to approved or rejected, accounts for any advance in the final settlement, and lets users withdraw from their available balance only once every 24 hours.
My implementation is intentionally small and dependency-free so that the business logic remains easy to review.
All newly created sales must start in pending state, and advance payout is credited exactly once per sale.
Reconciliation is a one-time operation per sale, and a sale is reconciled to approved or rejected.
Negative wallet balances are allowed after a rejected sale if an advance had already been paid.
My withdrawable balance is updated immediately when a withdrawal is initiated.
If a payout gateway later marks a withdrawal as failed, cancelled, or rejected, the amount is restored to the wallet after failed, cancelled, or rejected gateway status.
- My functional requirements include storing sales for each user and brand; process advance payout for eligible pending sales; prevent duplicate advance payout for the same sale; reconcile a sale to approved or rejected; calculate final settlement after reconciliation; maintain a withdrawable balance for each user; restrict withdrawals to one per 24 hours; recover failed, cancelled, or rejected withdrawals; and maintain an auditable history of balance changes.
- My non-functional requirements are idempotent payout processing, clear separation of responsibilities, auditable balance changes, easy local execution without external dependencies, and design that can be extended to a persistent database-backed implementation.
My design separates business state from money movement: Sale represents the affiliate earning event; Payout represents a transfer-related event such as advance payout, final settlement, withdrawal, or recovery; UserWallet represents the user's current withdrawable balance; and LedgerEntry represents an immutable audit record for wallet changes.
This separation makes retries, reconciliation, and payout failure recovery easier to reason about and easier to audit.
- My
Salefields are: sale_id, user_id, brand, earning, status, advance_paid, advance_paid_amount, finalized, created_at, updated_at. - My
UserWalletfields are: user_id, withdrawable_balance, last_withdrawal_at, created_at, updated_at. - My
Payoutfields are: payout_id, user_id, sale_id, amount, payout_type, status, idempotency_key, created_at, updated_at. - My
LedgerEntryfields are: entry_id, user_id, sale_id, payout_id, amount, entry_type, note, created_at. - My sale statuses are: pending, approved, rejected.
- My payout types are: advance, final, withdrawal, recovery.
- My payout statuses are: initiated, success, failed, rejected, cancelled.
The supplied requirements describe the lifecycle, core rules, entities, and enum values, but do not provide further implementation detail for the required database design, class design, APIs, edge-case handling, or working implementation. The exact advance eligibility rules, advance calculation base and precision, full settlement formula, and withdrawal-interval boundary behavior are also unspecified.
I developed DocuMind, a retrieval-augmented generation application for answering questions about uploaded documents.
I used Python, FastAPI, sentence-transformers, ChromaDB, and cross-encoder reranking for DocuMind.
I implemented document processing, text chunking, embedding generation, vector similarity search, and retrieval-based question answering in DocuMind.
I experimented with chunk overlap, retrieval quality, and reranking in DocuMind.
I used a retrieval workflow that selected the top five relevant chunks before generating an answer.
I worked on making DocuMind answers grounded in document content and providing source references.
DocuMind helped me understand embeddings, vector databases, semantic search, retrieval pipelines, and the practical challenges of RAG systems.
I developed Skill2Job using React, Node.js, Express, PostgreSQL, and Prisma.
I worked on matching candidate profiles and resumes with relevant job opportunities in Skill2Job.
I used Python-based resume processing and similarity scoring for Skill2Job.
I also explored caching, API integration, database operations, and rate-limit handling for Skill2Job.
I built backend functionality for a financial tracking application using Python, Django REST Framework, and PostgreSQL.
I worked on authentication, role-based access, transaction management, and income and expense APIs for the financial tracking application.
I implemented functionality for generating financial summaries from stored transactions.
I built a full-stack inverter load management application using FastAPI and React.
I used SQLAlchemy and Pydantic for database interactions and data validation in the inverter load management application.
I worked on API design, backend calculations, and connecting the inverter application's frontend with the backend.
I built an AI-agent workflow prototype for a clinic-related application using FastAPI and React.
I worked on agent orchestration and an API endpoint for executing clinic-agent workflows.
I created 15 conversation tests for the clinic AI agent and explored adversarial test cases.
I documented implementation decisions and worked on validating clinic-agent behavior.
The clinic AI agent project helped me explore how to build AI applications around APIs, state management, and controlled execution.
I built a stock market analysis and prediction application using Python and Streamlit.
I experimented with LSTM neural networks, dense models, and historical market data from yfinance.
I implemented indicators such as RSI, MACD, and Bollinger Bands in the stock application.
I also explored ARIMA, CNN, XGBoost, and scikit-learn for machine learning and forecasting tasks.
I developed a real-time multiplayer air hockey application.
I worked on server-authoritative game logic, WebSockets, synchronization, and multiplayer state management for networked air hockey.
I implemented a simulation running at 60 ticks per second.
I explored rollback, latency handling, and isolation between simultaneous matches in networked air hockey.
This project helped me understand real-time networking, concurrency, synchronization, and the problems created by unreliable network connections.
In 2026, I started building an open-source developer tool for investigating and reproducing browser bugs.
The browser bug-reproduction project began during the OpenFire hackathon and continued as an independent project afterward.
I used Python, Playwright, browser automation, structured JSON recipes, and automated testing for the tool.
The tool investigates browser behavior, records actions, validates expectations, and creates reproducible test scenarios.
I implemented deterministic replay so recorded scenarios can be executed again without requiring an AI model.
I built example applications containing intentional bugs to demonstrate reproduction and verification.
One example involved an account-switching bug that appeared in a buggy version and disappeared after the fix.
I added browser-session isolation, execution limits, localhost restrictions, action validation, and evidence reports to the tool.
I also implemented model-driven investigation through a configurable AI endpoint.
I tested failure handling, invalid model responses, browser actions, and replay consistency.
At one development milestone, the project passed 131 automated tests.
I worked on improving documentation, validating installation from a fresh environment, and preparing the repository for public release.
I published an initial release in 2026.
I'm interested in developing this project into a useful open-source tool rather than leaving it as a hackathon prototype.