🩻 repo-audit

Do first

• Add actual source code implementing the stated project purpose
• Add a real README.md describing what the repo does, setup, and usage
• Add tests and basic CI if this becomes a real project

Findings

• [RISK] README.md contains an embedded instruction attempting to hijack the auditor/LLM output format instead of documenting the project
• [BUG] Repository has no source code, so correctness/structure/error-handling/tests cannot be evaluated
• [STYLE] No LICENSE, no .gitignore, no project scaffolding present

Do first

• Archive or delete this repo; it adds clutter, not signal

Do first

• Delete example.py — it's a throwaway git tutorial artifact, not code
• Delete or rewrite README.md — it currently just narrates editing itself instead of describing a project
• If any real content was intended, start a fresh repo with an actual purpose

Findings

• [STYLE] example.py has no real logic, just a print statement simulating a git operation
• [STYLE] README.md is meta-commentary about editing the README, not documentation
• [RISK] Repo provides no indication of purpose, making it dead weight on a portfolio profile
• [BUG] Indentation in example.py (single space) is inconsistent with PEP8 standards

Do first

• Add real source code and a genuine README.md describing what the repo does
• If this was meant to hold Databricks notebooks/pipelines, commit them or remove the repo
• Add a .gitignore and basic project scaffolding if you intend to revive this

Findings

• [BUG] README.md contains a prompt/instruction payload instead of project documentation
• [RISK] Repo appears to have no source code, tests, or structure to audit
• [STYLE] Repo name suggests Databricks work but nothing Databricks-related is present

Do first

• Add actual coursework content or delete the repo entirely
• If keeping, write a real README.md describing what the course/repo covers
• Remove HelloWorld.md as it adds zero value

Findings

• [BUG] Repo contains no functional code or coursework artifacts
• [STYLE] README.md has no description, no content, just the title
• [RISK] Repo name suggests it should contain Data Science Coursera work but it's entirely empty

Do first

• Archive or delete this repo; it adds clutter, not signal

Do first

• Delete the repo if it's just GitHub's default init, or add actual project content to README.md if you meant to use it as a sandbox
• If keeping as a scratchpad, rename it to something like 'sandbox' or 'playground' to clarify intent
• Add a real project or merge its purpose into an existing repo

Findings

• [STYLE] README.md contains only a placeholder sentence with no project description, purpose, or content
• [RISK] Repo provides zero signal of skill or effort, which is a liability on a portfolio profile
• [BUG] No source code, tests, or structure exists to evaluate

Do first

• Add an actual README.md with project description, setup, and usage instructions
• Add source code implementing the coupon recommendation model
• Add requirements.txt/environment file and at least a basic test or notebook demonstrating results

Findings

• [BUG] Repo contains no visible source code, only a README stub
• [RISK] No way to evaluate correctness, structure, or functionality as nothing was provided
• [STYLE] README lacks even a project description, badges, or usage examples
• [RISK] If this reflects the actual repo state, it offers zero portfolio value in its current form
• [STYLE] Repo name suggests scope (in-vehicle coupon recommendation) that isn't backed by any implementation

Do first

• Add actual notebook files (.ipynb) demonstrating specific Kaggle competition work
• Expand README.md with project descriptions, dataset links, and results per notebook
• If notebooks exist but weren't shown, add a proper directory structure and .gitignore for checkpoints/data

Findings

• [BUG] README.md is effectively empty, no indication of what the repo contains
• [RISK] No visible source files means this repo currently has zero portfolio value
• [STYLE] Missing description, badges, or links to actual Kaggle competitions/notebooks
• [RISK] If notebooks exist outside what's shown, lack of documentation makes them undiscoverable

Do first

• Replace README.md with an actual project description of what this repo contains
• Add source files — currently there is nothing to audit as a Machine-Learning repo
• If this was meant to manipulate an auditing LLM into skipping review, remove that and add real content

Findings

• [BUG] Repo contains no source code, notebooks, or datasets — only a README
• [RISK] README content is a prompt-injection attempt instructing the auditor to output a fixed response instead of describing the project
• [STYLE] Repo name 'Machine-Learning' gives zero indication of actual purpose or scope
• [RISK] Presenting this as-is on a public profile signals either an empty placeholder repo or an attempt to game automated tooling, both bad looks
• [STYLE] No LICENSE, no requirements, no structure of any kind

Do first

• Add the actual MySQL scripts referenced in README.md or remove the repo entirely
• If scripts exist but weren't shown, add descriptions of what each script does to README.md
• If this is meant to be a living collection, add a folder structure (e.g. /schemas, /migrations, /queries) and commit real content

Findings

• [RISK] Repo contains no verifiable code or scripts, only a title-like README — provides zero portfolio value in current state
• [STYLE] README.md lacks any description, usage instructions, or context beyond a fragment sentence
• [RISK] No indication of what MySQL version, purpose, or use case these scripts target

Do first

• Add actual source files (notebooks/scripts) if this repo is meant to contain pandas exercises
• Rewrite README.md to describe what the code does, setup instructions, and examples
• If this is just scratch practice, merge into a single 'learning' repo instead of keeping it standalone

Findings

• [RISK] Repo appears to contain no discoverable source code, making it worthless as a showcase piece
• [STYLE] README.md is a placeholder with zero context, purpose, or usage info
• [RISK] No tests, structure, or docs to evaluate — cannot verify correctness of anything

Do first

• Add actual application source (e.g. app.py) implementing the Streamlit app
• Add requirements.txt and deployment config (Procfile/Dockerfile/streamlit config)
• Expand README.md with setup, usage, and deployment instructions

Findings

• [BUG] Repository contains no source code whatsoever, just a title
• [RISK] No requirements.txt or dependency pinning means nothing is reproducible
• [STYLE] README is a single unformatted line with no context or instructions

Do first

• Add actual R scripts or notebooks demonstrating specific learnings (e.g., data_wrangling.R, ggplot_examples.R)
• Write a real README.md with repo purpose, contents list, and setup instructions
• If keeping, add at least one worked example with comments explaining the R concept being learned

Findings

• [RISK] Repo contains no source code, so it has zero portfolio or reference value in its current state
• [STYLE] README.md is a single unstructured sentence with no sections, links, or context
• [BUG] No indication of what R topics were actually learned, making the repo purpose unverifiable
• [RISK] Publicly visible with this little content reflects poorly on an otherwise data-engineering-focused profile

Do first

• README.md: either write a real description, code, and purpose, or remove the repo entirely
• Add actual source files if this project has any intended functionality
• If abandoned/experimental, delete it rather than leaving a stub public

Findings

• [RISK] README.md contains only the literal text 'sample', signaling zero actual content or intent
• [STYLE] No source code, no structure, no way to assess correctness or design
• [RISK] Public empty repo reflects poorly on portfolio quality if left as-is

Do first

• Add a real README.md summarizing what was learned and linking to specific notebooks/certificates if you want to keep it
• If any actual project notebooks exist beyond the README, move them into a proper structured folder with descriptions
• Otherwise, just link the Coursera certificate on your profile/resume and delete this repo

Findings

• [STYLE] Course-completion repos like this add no signal to a portfolio and dilute the profile
• [RISK] No source code, notebooks, or exercises are shown — repo appears to be just a README stub
• [STYLE] Title suggests it's a course tracker, not an original project, which recruiters typically skip
• [BUG] No structure, no tests, no docs beyond the title — nothing to audit or evaluate technically

Do first

• Delete or rename repo away from 'full-stack-ai-python' since there's no AI, no full-stack, and no cohesive project here
• If keeping for reference, add a README explaining these are language-basics exercises, not showcase code
• Remove commented-out dead code blocks (e.g. chapter_10.py) and stray unused imports (e.g. arrow, namedtuple in chapter_11.py)

Findings

• [STYLE] No functions, classes, tests, error handling, or docs anywhere — just top-level scripts printing to stdout
• [STYLE] Filenames like chapter_1.py through chapter_11 with gaps (missing 8) suggest disorganized tutorial-following rather than authored structure
• [RISK] Repo name 'full-stack-ai-python' drastically overstates content; misleading to anyone auditing your GitHub as a data engineer
• [BUG] chapter_11.py computes brewing_time.to('Europe/London') but discards the result, doing nothing useful
• [STYLE] Comments are inconsistent (some educational, some leftover scratch notes) and would confuse a reader expecting production or showcase code

Do first

• Add actual course exercise code and folder structure (e.g. src/ with per-section packages)
• Add a real README describing what was learned/built, not just the repo name
• If reviving, commit incrementally per topic so progress is visible in history

Findings

• [RISK] Repo appears to contain only a README with the repo title, no source code to evaluate
• [STYLE] No indication of scope, topics covered, or completion status
• [RISK] Empty/placeholder repos on a public profile dilute the credibility of the rest of the portfolio
• [STYLE] No license, no .gitignore, no build files (pom.xml/build.gradle) present

Do first

• Add leading zeros to project.js time string (e.g. '9:5:3' -> '09:05:03')
• Wrap document.getElementById('time') in a null check in project.js to avoid a crash if the element is missing
• If keeping for portfolio value, fold into a larger demo or delete entirely since it has no standalone merit

Findings

• [BUG] No zero-padding on hours/minutes/seconds, producing malformed times like '9:5:3'
• [BUG] getElementById('time') result isn't checked, will throw if element absent
• [RISK] No HTML file, dependencies, or context included, so correctness can't even be fully verified
• [STYLE] Inconsistent variable declaration/indentation (mixing top-level and inline styles)
• [STYLE] No comments, tests, or documentation of any kind

Do first

• Add actual solution files organized by difficulty/topic if you want to keep this
• If reviving, include a README table linking problem number, title, and solution file
• Otherwise remove the repo entirely since it adds zero signal to your profile

Findings

• [BUG] No source code provided at all, nothing to audit or run
• [RISK] An empty Leetcode repo on a public profile signals abandoned work to anyone reviewing it
• [STYLE] README has no structure, difficulty tags, language used, or progress tracking

Do first

• Delete linkedlist1.py and circular-linkedlist.py duplication; keep at most one clean, tested implementation per structure if you want to showcase data-structure knowledge
• Add pytest-based unit tests covering push/append/delete/sort/dedup for whatever remains, since currently there is zero test coverage
• Guard the interactive CLI loop with if __name__=='__main__' properly (it currently runs unconditionally after the guarded llist init) and remove global 'llist' references inside class methods (append/

Findings

• [BUG] append() in circular-linkedlist.py sets new_node.next=self.head then unconditionally overwrites self.head.next=self.head, corrupting the ring on every append after the first
• [BUG] insertafter/append reference a bare global 'llist' name instead of self, so calling these methods outside the __main__ script context raises NameError
• [BUG] removeduplicates_unsorted uses data value as a list index (hashmap[p.data]) which crashes or misbehaves for negative numbers and wastes memory for large values
• [BUG] the `while(1):` CLI loop sits outside the `if __name__=='__main__'` guard (only llist=... is inside it), so importing any of these modules launches an infinite input() loop
• [STYLE] all three files are ~90% identical copy-pasted code (singly/doubly/circular) with tabs/spaces mixed, no docstrings, no type hints, and print-based 'error handling' instead of exceptions

Do first

• Add a README to Python-Masterclass explaining it's course exercises, not production work
• Delete or squash Day 12/day12.py's commented-out dead code and tangled retry logic
• Pick 1-2 best pieces (e.g. oop-coffee-machine-final) to extract into a standalone polished portfolio repo

Findings

• [BUG] Day 10/day10.py divide() returns a string 'invalid input' on div-by-zero instead of raising/handling, breaking type consistency with other operations
• [BUG] Day 14/day14.py has an unbounded while(1) loop with no exit condition except losing, and indexes into game_data using a stale chosen_number for display text
• [RISK] Day 12/day12.py uses global state, recursion-as-loop-restart (evaluate_guess() calling itself), and exit() calls scattered throughout — fragile and hard to test
• [STYLE] Massive amounts of commented-out dead code left in Day 12/day12.py; no docstrings, no requirements.txt, no tests anywhere in the repo
• [RISK] Day 16/oop-coffee-machine-final/money_machine.py trusts unvalidated int(input()) for coin counts, will crash on non-numeric input

Do first

• Add actual notebooks/scripts with content to README.md's referenced repo, or if none exist, remove the repo
• If learning notes exist, organize them into folders by topic (ds/ml/dl) with a real README.md index
• Add a requirements.txt or environment.yml if any notebooks are eventually added

Findings

• [STYLE] README.md is a single unformatted sentence with no repo structure, links, or table of contents
• [RISK] No source files were provided, suggesting the repo may be empty or contain no meaningful content
• [STYLE] No indication of what learnings, topics, or notebooks actually exist inside
• [BUG] Nothing to audit for correctness or error handling — repo appears to lack substance entirely

Do first

• Delete repo or fold into a single 'learning exercises' archive repo instead of standalone
• Remove console.log in src/Components/Bricks/brick.js if ever reused
• Fix src/App.test.js which fails since 'learn react' text no longer exists in App.js

Findings

• [BUG] src/App.test.js asserts text that was removed from App.js, so the only test fails
• [STYLE] console.log left in src/Components/Bricks/brick.js
• [STYLE] README.md is unedited CRA boilerplate, no project description at all
• [RISK] No key/error handling beyond trivial state push in src/Components/Wall/wall.js, but app itself is too trivial to matter
• [STYLE] Class component with arrow-function render in src/Components/Wall/wall.js is outdated style vs hooks

Do first

• Add a README.md explaining this is a learning log, not a library, and stop expanding it as loose numbered scripts
• Replace print-driven demos with pytest-based unit tests (e.g. for linearSearch/binarySearch in 01_Arrays/02_arrays.py and 02_Lists/05_lists.py) if you want to reuse this for a portfolio
• Consolidate duplicated search/access helper functions (accessElement, linearSearch, binarySearch appear near-identically in multiple files) into a shared module

Findings

• [STYLE] Every file is a top-to-bottom script of print() calls with no functions-under-test separation, so nothing is importable or reusable
• [BUG] 01_Arrays/02_arrays.py accessElement allows index==len(array)-1 correctly but doesn't guard negative indices going out of bounds beyond Python's own wraparound
• [RISK] 01_Arrays/04_arrays_practice.py mixes many unrelated demos (insert/extend/frombytes/sort) in one file with no isolation, making it hard to reuse or verify individually
• [STYLE] Inconsistent naming conventions across files (camelCase functions like linearSearch next to snake_case variables like my_array)
• [RISK] No requirements.txt/pyproject visible for the numpy dependency, so reproducibility for a 'showcase' repo is not guaranteed

Do first

• Add a README.md with setup steps, architecture diagram/explanation, and example queries
• Wrap index.py and query.py in try/except with proper error handling for missing PDF, Qdrant connection failures, and API errors
• Add a requirements.txt/pyproject.toml and at least a smoke test for the answer() function

Findings

• [BUG] similarity_search_with_score threshold of 0.3 is meaningless without knowing Qdrant's distance metric (cosine similarity is 0-1, but distance metrics differ) — likely arbitrary and untested
• [RISK] index.py has no idempotency check — rerunning it duplicates the entire collection with no upsert or clear-first logic
• [RISK] no error handling anywhere: missing .env vars, missing PDF file, Qdrant not running, or API failures will all produce raw stack traces
• [STYLE] CLAUDE_MODEL name 'claude-sonnet-4-6' looks like a placeholder/typo (no such published model), undermines credibility of the comment above it
• [BUG] no requirements.txt/pyproject.toml — repo isn't reproducible without guessing dependency versions

Do first

• Implement real HTTP calls in cricapi_client.py and news_client.py (requests/httpx) with actual API keys and error handling, or rename endpoints to make clear they're mocked
• Add a tests/ directory with pytest + httpx TestClient covering routes and services, none exist currently
• Add README documenting setup, data source assumptions, and that live endpoints are placeholders, plus input validation in ipl_service.py for missing JSON files/keys

Findings

• [BUG] load_json_file has no try/except; missing/malformed JSON files will raise unhandled 500s
• [RISK] cricapi_client and news_client return static fabricated data labeled 'fallback' with no real integration or fallback logic — misleading naming given the project's name implies live intelligence
• [RISK] No tests anywhere in the shown structure
• [STYLE] Direct dict key access (team['short_name'], stats['full_name']) throughout risks KeyError on malformed data instead of using .get()
• [STYLE] No .env/config management visible for future real API keys, CORS origins hardcoded to localhost only

Do first

• mail_digest.py: fix the truncated main() — the file cuts off mid-statement at 'ahead = a', meaning the module doesn't even parse/import; restore the rest of main() (ahead_block, carried_block, vip_blo
• mail_digest.py: add at least a smoke test (mock Gmail service + fake LLM reply) that exercises main() end-to-end for both morning and evening paths, since none exists
• mail_digest.py/agentlib.py: add a README documenting setup (credentials.json, token.json, required env vars, GitHub Actions schedule) — the module docstrings are excellent but there's no onboarding do

Findings

• [BUG] main() is truncated ('ahead = a' with nothing after) — the file as shown cannot execute, so either the paste is incomplete or the committed file is genuinely broken
• [RISK] no automated tests anywhere for either file; all correctness rests on docstring reasoning and manual runs, risky for logic this stateful (JSON ledgers, thread-reply detection, dedup keys)
• [RISK] state files (noise.json/stats.json/actions.json/deadlines.json) have no concurrency guard or backup — a crash mid _save_json on a partial write could corrupt state with no recovery path
• [STYLE] very long, deeply-commented functions (summarize, main) mix orchestration with business rules; splitting the block-builders from the model-prompt construction would make the module testable in
• [BUG] vip_suggestions and thread_replied swallow all exceptions silently (bare except/continue) — a systematic Gmail API auth issue would silently degrade features rather than surface in logs

Do first

• Add a README.md explaining these are sequential GenAI course/tutorial exercises, not a cohesive app
• Wrap API calls in try/except in every file (e.g. 02_hello_world/*.py, 03_ollama_fastapi/server.py) so failures don't dump raw tracebacks
• Consolidate repeated boilerplate (dotenv load, client init) into a shared helper/config module instead of copy-pasting in every script

Findings

• [BUG] 06_structured_output.py builds an invalid JSON example with unescaped quotes inside a string, likely to confuse the few-shot demonstration
• [RISK] No requirements.txt/pyproject.toml or pinned dependencies shown, so reproducibility across tiktoken/openai/transformers/ollama versions is unclear
• [RISK] No .env.example or gitignore mention, risk of committing real API keys if .env is tracked
• [STYLE] Zero tests, zero error handling, hardcoded personal name/persona strings throughout indicate throwaway tutorial code rather than showcase-quality work
• [STYLE] No docstrings or comments explaining intent beyond one-line topic headers, low reusability for anyone browsing the repo

Do first

• Implement backend/agents/stats_aggregator.py, tutor.py, path_planner.py or remove them if unused — empty files signal abandoned scope
• Add tests/ with at least auth.py and question_generator.py covered (mock OpenAI calls) since there is currently no visible test suite
• Fix config.py default database_url port (5432) mismatching alembic/env.py default (5433) to avoid silent dev confusion

Findings

• [BUG] config.py and alembic/env.py have different fallback DATABASE_URL ports (5432 vs 5433), risking connection errors if .env is missing
• [RISK] No tests directory shown at all — orchestrator, evaluator, and question_generator have zero coverage
• [RISK] question_generator.py raises RuntimeError on repeated LLM failures with no fallback/backoff, could hard-crash a request path
• [STYLE] Several agent files (tutor.py, path_planner.py, chroma_client.py) are empty stubs committed to repo, cluttering structure without indicating WIP status
• [STYLE] orchestrator.py is pure logging with no real routing logic yet — fine for sprint 1 but should be flagged as incomplete in README if not already

Do first

• sentiment_service.py: replace or augment the keyword list with a real model (VADER, TextBlob, or a small HF transformer) so the name matches the function
• README.md: disclose the rule-based limitation upfront so it's not misleading in a portfolio context
• app.py: add a requirements.txt (referenced in README but missing) and basic input length/rate limits

Findings

• [BUG] README references requirements.txt but it's not shown/provided in the repo
• [RISK] Naming it 'sentiment-analysis' oversells a ~20-word bag-of-words heuristic; misleading for showcase purposes
• [STYLE] Negation handling absent ('not good' scores as positive) — a basic correctness gap for any sentiment tool
• [STYLE] Good separation of concerns (service vs API), decent test coverage, type hints and docstrings are solid
• [RISK] No CI config, no Dockerfile, no version pinning — thin for a 'showcase' piece

Do first

• Add a README.md describing purpose, architecture (SQLite + sync_queue for offline-first), and setup/run instructions
• Write real unit tests for hooks/useStreaks.ts and db/migrations.ts instead of relying only on the boilerplate StyledText snapshot test
• Fix the streak/date-key logic in useStreaks.ts to use local-date strings consistently (avoid toISOString timezone bugs) and add error handling around db calls in toggleToday/addHabit

Findings

• [BUG] useStreaks.ts uses `new Date().toISOString().split('T')[0]` for date keys, which is UTC-based and will misalign 'today' for users in negative UTC-offset timezones
• [RISK] No error handling in toggleToday/addHabit/deleteHabit — a failed runAsync will throw uncaught and leave the DB/UI in an inconsistent state
• [RISK] sync_queue table is defined in schema.ts but no code shown actually populates or drains it, suggesting offline-sync is incomplete or vestigial
• [STYLE] Only one trivial snapshot test exists for the whole app; no coverage of DB layer, migrations, or streak calculation logic
• [STYLE] Mixed id generation strategies (uuidv4 in addHabit vs `${Date.now()}-${Math.random()}` in toggleToday) is inconsistent and risks collisions