frontend-docs
Shipped: A guide for the next contributor
I documented the Personal Reading List project for future contributors. The documentation explains the code layout and architectural reasoning, where new features should be added, which files may need to be changed, how to run and check the project, what a passing run looks like, and which parts of the application are fragile. The repository includes both a user-facing README and a contributor-focused CONTRIBUTING.md so that another developer can understand, run, test, and safely extend the project. Repository: https://github.com/vanshika2723/Personal-reading-list.git Built for the Verified Frontend Internship · Documentation
Shipped: A README for a stranger
Provided an exhaustive, reviewer-ready README.md satisfying all brief criteria: 1. Stranger-ready setup: Documents concrete minimum runtime versions (Node.js v18+, Python 3.8+, modern browser versions) with 3 independent ways to run locally under 5 minutes without assumptions. 2. Environment variables: Fully audits all variables/endpoints, showing default fallbacks and confirming zero secret requirements. 3. Architecture decisions: Explains zero-dependency vanilla choices and AbortController timeout mechanisms. 4. Analytical limits & honesty: Explicitly outlines what the data establishes versus what it cannot claim (earthquake prediction, structural damage), alongside known technical constraints (50-item display cap, mock service limits). Repository: https://github.com/GhulamMustafaAnsari/earthquake-dataset-viewer Live: https://GhulamMustafaAnsari.github.io/earthquake-dataset-viewer/ Built for the Verified Frontend Internship · Documentation
Shipped: Three decisions, written down
I updated the README for the Canva Export Menu replica to fully satisfy the documentation requirements. You can verify the acceptance criteria by scrolling down to the 'Architectural Decision Record' section in the README on GitHub. It includes: Three major technical decisions (Vanilla JS over frameworks, proactive offline checking, and CSS pseudo-elements for toggles). The alternatives that were considered for each. The explicit costs/downsides of each decision. The third decision (Pure CSS Toggles) explicitly describes an approach that has since proved awkward to maintain. Repository: https://github.com/Carmy4/canva-export-menu Live: https://carmy4.github.io/canva-export-menu/ Built for the Verified Frontend Internship · Documentation
Shipped: Three decisions, written down
I created documentation for my Coding Practice Tracker project. I added a decision record in DECISIONS.md covering three important technical decisions, the alternatives considered, the reasons for choosing them, and the trade-offs of each decision. I also updated the README with the project architecture, setup instructions, and a link to the decision record. The reviewer can open the GitHub repository and check DECISIONS.md for the three documented decisions, alternatives, reasoning, and costs/trade-offs. The README explains the application architecture and how to run the project locally, and it links directly to the decision record. The documentation is written so the reasoning can be understood without needing prior knowledge of the code. Repository: https://github.com/Ateefa-Syed/coding-practice-tracker Built for the Verified Frontend Internship · Documentation
Shipped: Three decisions, written down
I built the documentation for mern-auth-client, a React SPA with email-activated sign-up, sign-in, Google/Facebook login, password reset and role-gated pages. README.md covers the architecture, route table, session flow, run steps for macOS/Linux and Windows, and known issues. DECISIONS.md records three costly-to-reverse decisions (own identity system, JWT in a JS-readable cookie plus localStorage, and a CRA SPA on a separate host). Each entry lists the alternatives considered, the reason for the choice, its cost, and the cost to reverse. The criteria map one-to-one to its headings: "Alternatives considered" and "What it costs" in each entry, and the "Status: proved awkward" label on Decision 2 (the jsonwebtoken-in-the-browser fallout is also called out under Decision 1). Repository: https://github.com/abbasg-dev/mern-auth-client Built for the Verified Frontend Internship · Documentation
Shipped: A README for a stranger
What I built and how the acceptance criteria are met: I built a React + Vite GitHub Repository Search application that allows users to search GitHub repositories through the public GitHub REST API and view repository details such as name, description, language, stars, and last updated date. The README is written for a first-time user and provides concrete prerequisites, installation and run commands, environment-variable requirements, architecture, project structure, design decisions, available commands, and known limitations. A reviewer can verify the acceptance criteria directly by following the README from a fresh clone, running the documented commands, and checking the documented idle, loading, results, empty, and error states. The implementation also includes responsive behavior, visible keyboard focus states, semantic HTML, and accessible status/error messaging. The project was additionally verified with npm run lint (0 warnings/errors) and npm run build (successful production build). Repository: https://github.com/kiths-bit/github-repository-search Built for the Verified Frontend Internship · Documentation
Shipped: Three decisions, written down
I created a decision record for Nodex documenting the major architectural decisions, alternatives considered, reasoning, and trade-offs. The DECISIONS.md covers the local-first architecture, Web Worker processing, React Flow + Dagre, Zustand state management, IndexedDB persistence, URL-based sharing, and primitive-only graph editing. The reviewer can open DECISIONS.md in the repository to verify the decisions and their associated costs/trade-offs. The existing README already covers the project architecture, setup instructions, testing, scope, and deliberately unimplemented features. Repository: https://github.com/riki-k-dev/nodex Live: https://nodex-jv.vercel.app Built for the Verified Frontend Internship · Documentation
Shipped: A README for a stranger
DropLink Send files and code folders between two laptops on the same Wi-Fi, directly from the browser. No account, install, cloud upload, or manual zipping. Demo: https://droplink-rl1f.onrender.com/ Run locally Prerequisites Node.js 18+ (developed on Node 22) npm Two devices on the same local network for transfers Open http://localhost:3000 . To use a second laptop, open: Both devices must be on the same Wi-Fi/network. The host computer's firewall must allow Node.js on private networks. Environment variables | Variable | Required | Purpose | | ------------- | -------- | -------------------------------------------------------- | | PORT | No | Changes the server port. Set this to any available port. | | CODE TTL MS | No | Changes pairing-code expiry, mainly useful for testing. | No API keys or other secrets are required. How to use 1. On laptop A, click Get pairing code . 2. On laptop B, enter the 6-digit code and click Connect . 3. On A, select files or a folder and click Send . 4. On B, click Accept , then use the Save links. Codes expire after 5 minutes and can only be used once. Files and folders Transfers support up to 50 items / 500 MB per batch . Folders are zipped in the browser before sending. By default, these are skipped: .env files are also skipped by default because they may contain secrets. Include .env files can be enabled when needed. .env.example files are always included. DropLink does not read .gitignore . How it works The server is used only for pairing and WebRTC signaling. After pairing, browsers establish a direct WebRTC data channel and send files directly between the two devices. No STUN or TURN servers are configured, so files stay on the local network. Tests The WebRTC transfer flow is also tested manually. Deployment DropLink requires Node.js and WebSockets, so static hosting such as GitHub Pages will not work. Render: use the included render.yaml Blueprint. Railway: create a service from the repository; it should detect npm start and provide PORT . Known limitations Both devices must be on the same local network. Guest/public Wi-Fi may block device-to-device connections. Deployed pairing requires internet access; file contents do not pass through the server. Transfers are limited to 500 MB / 50 items. Interrupted transfers cannot resume. The folder skip list is fixed and does not follow .gitignore . Internet transfers, Bluetooth discovery, transfer history, backup/sync, and whole-drive/app copying are not supported. Received files are held in browser memory until saved. Design decisions Why a pairing code? Browsers cannot freely perform nearby-device or Bluetooth discovery, so DropLink uses a 6-digit code instead. Why no STUN/TURN? They could enable more network configurations, but TURN would relay file data through a server. DropLink intentionally keeps transfers local. Why ZIP folders? Direct folder writing is not consistently available across browsers, so folders are sent as ZIP files instead. License MIT. Bundled fflate is MIT-licensed.
Shipped: A README for a stranger
A documentation criteria fully satisfied. A comprehensive README.md is merged into the repository containing exact tech stack versions, a 20-minute local setup guide with concrete prerequisite versions, client-side configuration notes, architecture decisions, focus-management mechanics, explicit feature comparisons (omissions and improvements), and known limitations/boundary conditions. Repository: https://github.com/onaolapomay/date-picker-rebuild Live: https://datepickerrebuild.netlify.app/ Built for the Verified Frontend Internship · Documentation
Shipped: A README for a stranger
Repository: https://github.com/Kam-ino/DevConnect-Internship/tree/main/Stillroom Built for the Verified Frontend Internship · Documentation
Shipped: API Response Debugger — a local-first dev tool
What did you build? - A lightweight browser-based API debugging tool for frontend development. It lets users configure HTTP methods, URLs, headers, query parameters, and request bodies, then send requests and inspect status, timing, response size, and formatted responses. - Built incrementally across 8 scoped PRs, with features including error states, query parameters, JSON highlighting, request history, retry, response size, in-response search, and saved favorites. - No backend, build step, or dependencies — plain HTML/CSS/JS. How can a reviewer verify the acceptance criteria? - Repository: GitHub commit/PR history shows each feature and its implementation. - README: Documents architecture, setup, features, and intentionally excluded scope. - Error states: Invalid URLs, network/CORS failures, timeouts, invalid/empty responses, and 4xx/5xx responses are handled visibly. - Live demo: https://sindhu-dev02.github.io/api-debugger/ - DECISIONS.md: Documents key technical decisions, alternatives, trade-offs, and a real bug discovered during development. Repository: https://github.com/sindhu-dev02/api-debugger Live: https://sindhu-dev02.github.io/api-debugger/ Built for the Verified Frontend Internship · Documentation
Shipped: A guide for the next contributor
What I Built CommandVault — A keyboard-first developer snippet and command cheat sheet (React 19 + TypeScript + Vite) with: Dual Workspaces: Zed/Helix Terminal TUI and Linear 3-Pane (toggleable via ⌘M). Craft Light & Dark Themes: High-contrast light mode with visible macOS-style scrollbars and pastel tags (toggleable via ⌘T). Live Placeholder Substitution: Real-time argument editing for commands containing variables like <container or <port . Zero-Clipping Global Tooltips & Popovers: Portal-rendered tooltips and micro inline delete confirmation bubbles. 100% Viewport-Fit UI: The outer frame stays locked to the visible screen (100dvh) without page scrolling, while lists and inspector panes scroll independently. How a Reviewer Can Verify Acceptance Criteria Outer Viewport & Inner Scrollbars: Open the app—the outer window fits on screen with zero whole-page scroll. Scroll the snippet list or inspector to verify smooth inner scrollbars and an unclipped bottom shadow. Dual Workspaces: Press ⌘M (or click header tabs) to switch between Zed TUI and Linear 3-Pane. Refresh the page to verify it persists. Light Theme: Press ⌘T (or click Sun/Moon icon) to verify high-contrast light surfaces, visible dark scrollbars, and colored category tags. Tooltips & Delete Popover: Hover over the Copy button to verify the tooltip floats cleanly below with its arrow centered. Click the Trash icon to verify the inline "Delete snippet?" bubble pops up. Favorites Filter in Zed TUI: Press ⌘P on a snippet to star it, then click [★ FAVS] in the category bar to filter pinned commands. Code & Build Checks: Run npm run build in terminal to confirm a passing build with 0 TypeScript errors. Check CONTRIBUTING.md and README.md for full architecture and usage guides. Repository: https://github.com/aleewains/dev-snippets Live: https://commandvault-tau.vercel.app/ Built for the Verified Frontend Internship · Documentation
Shipped: A README for a stranger
Repository: https://github.com/Raunakshukla90/DevConnect FinalProject Built for the Verified Frontend Internship · Documentation
Shipped: Three decisions, written down
Documentation for Climate Days: a README with run instructions, usage and data limits, plus a decision record covering three key decisions (data source, single large request, localStorage cache) with alternatives and costs. Repository: https://github.com/e-dedaj/climate-days Live: https://climate-days.vercel.app/ Built for the Verified Frontend Internship · Documentation
Shipped: Three decisions, written down
I documented Clinical Trial Finder with a README (how to run it, how to use it, what the data can’t tell you) and a DECISIONS.md that explains three choices: calling the API live from the browser, cleaning up each record before showing it, and letting the API handle search and filtering. Each one lists the alternatives I weighed and the costs. Repository: https://github.com/marthahere/clinical-trial-finder Live: https://marthahere.github.io/clinical-trial-finder/ Built for the Verified Frontend Internship · Documentation
Shipped: A guide for the next contributor
Documentation Requirements – Contributor Guide 1. A CONTRIBUTING.md file has been added to the repository. 2. The project structure is explained, including the purpose of the main folders and files. 3. The documentation explains where new features should be added. 4. Guidance is provided on which existing components may need to be updated when adding a feature. 5. Instructions are included for installing dependencies and running the project locally. 6. The commands for building and linting the project are documented. 7. Expected results of successful build and lint checks are explained. 8. Fragile parts of the code are identified, including ingredient calculations, serving controls, accessibility announcements, and responsive layout. 9. The README includes information about the project, its main features, technologies, and how to run it locally. 10. The documentation provides clear guidance to help future contributors understand and extend the project without breaking existing functionality. Repository: https://github.com/humaeidmansur/accessible-recipe.git Live: https://humaeid-internship-reciepe-project.netlify.app/ Built for the Verified Frontend Internship · Documentation