You are browsing as a guest. Sign up (or log in) to start making projects!

DevaanshPathak

@DevaanshPathak

Joined June 20th, 2026

  • 30Devlogs
  • 13Projects
  • 6Ships
  • 75Votes
Open comments for this post

32m 46s logged

Added a scan counter which shows live number of ports scanned/total ports to be scanned.

Added hyperthreading using ThreadPoolExecutor for faster scanning.

Fixed minor bugs, added a README.md file and changed a lot of strings to formatted strings (f-strings) so that the code does not looks scuffed.

Now I am planning to add command line arguments using argparse for target, port range, worker count, timeout and verbose mode.

0
0
3
Open comments for this post

23m 22s logged

Started building a basic port scanner in python to learn about networks, ports and stuff.
P.S. i’m building it without using any AI.

I built a really basic script as of now which uses the socket python library to connect to the given port range.

If a connection succeeds then the port is open, if refused then it is closed and if times out then it is filtered out by a firewall.

I also added if else statements to see that the user input ports stay between 1 and 65535.

Also used try and except statements to handle errors gracefully and give out a message.

0
0
1
Open comments for this post

45m 7s logged

Added signature interaction for APOD Console: a boot overlay that gates initial rendering until both the simulated console startup and the real APOD fetch are ready.

  • Added boot sequence lines:
    • > ESTABLISHING DEEP SPACE NETWORK LINK...
    • > AUTHENTICATING APOD UPLINK...
    • > DECODING IMAGE PACKET...
    • > LINK ESTABLISHED.
  • Rendered the boot log in a <pre aria-live="polite">.
  • Added a progress bar that fills during typing and enters a waiting animation if the APOD response is still pending.
  • Cross-fades from the boot overlay into the main console only after boot and data are both complete.
  • Added a fixed, low-opacity CRT scanline overlay across the viewport.
  • Honored prefers-reduced-motion by skipping the boot typing sequence and going straight to the normal loading/content flow.
  • Kept retry behavior on the plain loading path instead of replaying the boot overlay.
0
0
0
Open comments for this post

1h 17m 54s logged

Today we finished WebOS 1 and got it ready as the final Stardance submission.

The project is now a complete browser desktop instead of a rough prototype. It has a Windows-style desktop surface, custom desktop icons, a taskbar, a Start menu, draggable and resizable windows, minimize/close controls, focus layering, snapping, persistent layouts, and a public boot sequence that does not block visitors behind a password gate.

The custom apps are also in place:

  • Terminal with hardcoded commands like system info, ls, whoami, ping, and an easter egg.
  • System Monitor with animated fake CPU, RAM, uptime, graph traces, and themed process rows.
  • WordPad-style blog reader that opens copied Markdown posts from the portfolio site.
  • Profile, Research, Contact, and Welcome windows that make the OS feel like a personal portfolio system instead of a generic guide clone.

The final polish pass focused on making the project feel shippable. I replaced generic letter icons with custom SVG icons, tightened the taskbar and Start menu, checked window behavior across desktop, tablet, and mobile widths, tuned the animations, and verified that the static export works from the generated out/ folder.

The deployed site is live at:

https://os.devaanshpathak.com

At this point, WebOS 1 meets the mission requirements: it has multiple draggable windows, a distinct visual identity, extra features beyond the guide, no real login gate, and a public link for reviewers. The README now points to the live site, and the devlogs are ready for the Stardance portal.

0
0
2
Open comments for this post

20m 16s logged

Initialized APOD Console as a Vite-powered Vanilla JavaScript project and added the first functional APOD API integration.

Completed

  • Created the project documentation set: README.md, AGENTS.md, .gitignore, and local-only ROADMAP.md.
  • Added Phase 0 scaffold files:
    • package.json with Vite dev, build, and preview scripts.
    • vite.config.js with GitHub Pages base path /apod-console/.
    • .env.example with VITE_NASA_API_KEY=your_key_here.
    • index.html with Google Font links for JetBrains Mono and IBM Plex Sans.
  • Added Phase 1 app code:
    • src/main.js fetches today’s APOD from https://api.nasa.gov/planetary/apod.
    • Uses import.meta.env.VITE_NASA_API_KEY || 'DEMO_KEY'.
    • Renders APOD title, date, explanation, and media.
    • Supports image responses with <img> and video responses with an iframe.
    • Includes loading and retryable error states.
    • src/style.css provides a temporary mission-console baseline so the fetched data is readable before the full design phase.

Validation

  • Ran npm exec --yes --package [email protected] vite build.
  • Build completed successfully.

GitHub

  • Pushed Phase 0 to main in commit 854ae25.
  • Pushed Phase 1 to main in commit 6628354.

Next

Phase 2 should replace the temporary baseline styling with the full mission-control design system: palette custom properties, telemetry layout, viewfinder frame, and stronger console composition.

0
0
0
Open comments for this post

23m 32s logged

Today I rebuilt the WebOS interface to feel much more like a real desktop OS. The old version had windows, but it still felt like a dashboard. This pass added a proper desktop surface with wallpaper, desktop shortcuts, a bottom taskbar, a Start button, pinned apps, active app buttons, and Windows-style window chrome.

I also completed the planned Phase 3 custom features.

The terminal app now supports hardcoded commands:

  • system info
  • ls
  • whoami
  • ping
  • stardance as the easter egg
  • plus help, clear, and reset-layout

Window snapping works by dragging windows to screen edges or corners. Edges snap to half-screen layouts, corners snap to quarter-screen layouts, and a blue preview rectangle shows the snap target before release.

The system monitor is now animated. It has fake CPU, RAM, IO, uptime, a moving bar graph, and a fake process table with WebOS-themed process names.

Window layout now persists in localStorage. Open apps, minimized state, window position, size, and z-index are saved and restored after reload. I also added a reset path through the terminal and Start menu.

The boot sequence is now more complete: BIOS-style firmware lines, fake hardware checks, portfolio disk mount, fake login handoff, and automatic transition to the desktop. It still does not require a password.

I copied portfolio assets from D:/devaansh-website into this repo:

  • public/portfolio/me.png
  • 29 Markdown blog files under public/portfolio/blogs/
  • a generated manifest.json for the blog reader

The new WordPad app loads that manifest, lists the copied Markdown files, and opens them in a readable document-style page.

Verification: npm run build passed, npm audit --omit=dev showed zero vulnerabilities, and Playwright confirmed terminal commands, WordPad loading, edge/corner snapping, layout persistence, and no page-level scrolling.

0
0
1
Open comments for this post

22m 38s logged

The biggest change is the core windowing system. WebOS now has a reusable window model that tracks app id, title, position, size, open state, minimized state, and z-index. Windows can be dragged by their title bars, resized from the lower-right handle, focused by clicking, minimized to the taskbar, closed, and reopened through launchers.

I also added the baseline desktop experience for the Stardance mission:

  • BIOS-style boot overlay with fake login text, but no password gate.
  • Desktop background with grid/scanline styling.
  • Top bar with clock, open-window count, and static export status.
  • Desktop launcher dock.
  • Taskbar for open and minimized apps.
  • Welcome window.
  • Profile window.
  • Research/SRE-Zero window.
  • System monitor-style app window.
  • Contact/uplink window.

For profile content, I used the local D:/devaansh-website repo instead of inventing copy. The WebOS apps now include Devaansh Pathak, CS + AI/ML student, reliable LLM agents, RL environments, evaluation systems, AI infrastructure, SRE-Zero, GitHub, LinkedIn, and email contact details.

I tested the implementation with npm run build, which passed and generated static routes. I also used Playwright against the local dev server to check multiple-window behavior: launching a window, minimizing and restoring from the taskbar, closing and reopening, dragging a window, resizing another window, and focus/z-index updates.

Next step: Phase 3 custom features, starting with the functional terminal commands and then window snapping/tiling.

0
0
2
Open comments for this post

19m 25s logged

Today I completed Phase 0 for WebOS 1, my Hack Club Stardance WebOS 1 mission project. The project now has a real Next.js and Tailwind CSS scaffold instead of only planning docs.

I added the App Router structure, TypeScript config, PostCSS/Tailwind setup, and a next.config.ts file with output: "export" so the site can stay compatible with static hosting. I also installed dependencies and generated the package lockfile.

The first page is a static desktop shell, not the full OS yet. It establishes the visual direction: dark terminal tones, compact desktop launchers, a boot-preview window, and a placeholder system monitor panel. This gives the project an embedded-systems and homelab identity before I start building actual window behavior.

I also checked the setup with a production build. npm run build completed successfully and generated static routes for / and /_not-found. npm audit originally flagged Next’s nested PostCSS version, so I added an override to use the patched PostCSS release and confirmed the audit now reports zero vulnerabilities.

Current state:

  • Next.js scaffold is in place.
  • Tailwind CSS is connected through PostCSS.
  • Static export is configured.
  • The base desktop layout shell exists.
  • No password gate or server runtime has been added.

Next step: Phase 1, building the core windowing system with draggable, resizable, focusable windows.

0
0
3
Ship

gitscope is a read-only terminal UI for exploring git commit history: log rows, branch topology, refs, and selected-commit diffs in one local view. It exists as a focused personal/portfolio project for making history easier to scan without adding git workflow actions.

  • 5 devlogs
  • 4h
  • 9.14x multiplier
  • 39 Stardust
Try project → See source code →
Open comments for this post

1h 37m 47s logged

Finishing v1 of GitScope !! :)

This session, I tightened the project for public viewing and basic use. The documentation now matches the implemented behavior, the app was checked against the design document, and the project version was moved to 1.0.0 for the planned v1.0 release line.

What Changed

  • Updated the TUI to follow DESIGN.md more closely.
  • Placed the app inside a single framed terminal-style window.
  • Removed the default Textual footer so the custom status bar owns the bottom edge.
  • Styled the title bar, refs sidebar, commit table, selection state, graph gutter, diff pane, diff overview strip, and status hints with the documented color palette.
  • Kept the UI read-only: ref selection changes the viewed log only and never checks out a branch.
  • Updated README status, key bindings, bounded-loading notes, and known v1 limitations.
  • Marked the readiness pass complete in the roadmap.
  • Updated package and CLI version strings from 0.1.0 to 1.0.0.

Release Preparation

The intended public release target is GitHub Release v1.0, with Windows and Linux builds to be published later.

No release artifacts were built in this pass. No GitHub release was created. No push was performed.

Known v1 Limits

  • Line-level diffs only; no word-level intraline highlighting.
  • No config files, custom themes, or plugin system.
  • No remote operations and no network calls.
  • No mutating git operations.

Verification

  • py -m pytest passed with 31 tests.
  • py -m pip install . installed the project from source.
  • gitscope --version reported the package version.
  • A Textual smoke check in the local repository populated the refs, history table, selected commit, diff pane, status bar, and exported screenshot.
  • Source scans confirmed subprocess use remains isolated to the backend and no network libraries or mutating git command shapes were added.

Releases:

  1. https://github.com/DevaanshPathak/gitscope/releases/tag/v1.0
  2. https://pypi.org/project/devaansh-gitscope/1.0.0/
0
0
3
Ship Pending review

Embedded firmware images are often distributed as .hex or .bin files with little context about their memory layout. Before flashing, diffing, reverse engineering, or auditing a firmware image, it is useful to answer basic questions:

- Which address ranges are actually populated?
- Are there gaps, overlaps, or suspicious discontinuities?
- Does the image contain likely vector tables for ARM Cortex-M targets?
- Which regions look like code, padding, compressed data, or encrypted data?

BINLens exists to provide that first-pass inspection from the command line with no external dependencies. The target use case is practical STM32 firmware work, not full disassembly or reverse engineering.

  • 3 devlogs
  • 5h
Try project → See source code →
Open comments for this post

1h 36m 5s logged

BINLens is now documented, tested, manually validated on STM32-style HEX/BIN inputs, and prepared for the v1.0 GitHub release.

Output Polish

Updated the CLI report for stable terminal output:

  • clearer input summary
  • consistent region, gap, overlap, entropy, and vector-table sections
  • -v now clearly exposes source chunks and entropy windows
  • --heatmap renders a compact entropy view
  • unknown input formats now include the input path in the error message

Generated the requested screenshot:

  • devlogs/ss.png

The PNG is rendered from real binlens output against testfiles/STM32-DEMO.hex.

Hardening

Cleaned up invalid-input behavior:

  • case-insensitive --format
  • case-insensitive .hex, .ihex, and .bin extension inference
  • explicit rejection for overly long input paths
  • clearer help text for --base and -v
  • raw BIN size guard before allocation

Validated common error cases:

  • invalid entropy chunk size
  • invalid format
  • bad Intel HEX checksum
  • missing input file

Documentation

Updated:

  • README.md
  • PRD.md
  • ARCHITECTURE.md
  • CONTRIBUTING.md

Added:

  • TESTING.md

The docs now describe the actual v1 behavior instead of the early scaffold state.

Test Corpus

The fixture set now covers:

  • minimal Intel HEX
  • extended linear address
  • extended segment address
  • bad checksum
  • record after EOF
  • STM32-like vector table image

The test workflow is documented in TESTING.md.

Manual Validation

Validated real STM32 HEX:

testfiles/STM32-DEMO.hex

Converted it to raw BIN with objcopy and validated:

build/manual/STM32-DEMO.bin

Both paths detected:

  • address span 0x08000000 - 0x08001E2F
  • high-confidence vector table at 0x08000000
  • reset handler target inside loaded firmware
  • entropy heatmap output

Build Checks

Native Windows GCC:

test_bin_loader: ok
test_entropy: ok
test_hex_parser: ok
test_memmap: ok
test_smoke: ok
test_vector_table: ok

Docker Linux:

make clean
make test
make

Docker/Zig macOS check:

  • Mach-O x86_64 binary produced
  • Mach-O arm64 binary produced

Docker initially had a Desktop engine error and was recovered by restarting Docker Desktop.

Release State

Released on GitHub with compiled binaries for Windows and Linux.
https://github.com/DevaanshPathak/BINLens/releases/tag/v1.0

0
0
0
Open comments for this post

41m 20s logged

BIN Loading and Memory Map

Implemented raw .bin loading:

  • opens files in binary mode
  • maps bytes at --base
  • stores the image as one source chunk
  • handles empty files
  • rejects address overflow
  • reports file errors with diagnostics

Extended BlFirmwareImage with owned analysis data:

  • reconstructed regions
  • gaps
  • overlaps

Implemented bl_memmap_reconstruct:

  • sorts source chunks by address
  • merges adjacent chunks
  • merges overlapping chunks while preserving first-seen bytes
  • records sparse gaps
  • records overlaps as identical or conflicting

CLI output now includes:

  • input metadata
  • source chunks with -v
  • memory regions
  • gaps
  • overlaps

Added tests:

  • test_bin_loader.c
  • test_memmap.c

Covered base-address mapping, overflow rejection, adjacent merge, sparse gaps, identical overlaps, and conflicting overlaps.

Entropy and Cortex-M Analysis

Implemented Shannon entropy without requiring -lm, keeping the Makefile dependency-free.

Entropy is now reported:

  • per reconstructed region
  • per fixed-size chunk in verbose mode
  • as an ASCII heatmap with --heatmap

--entropy-chunk controls the chunk size.

Implemented Cortex-M vector table detection:

  • checks common aliases like 0x00000000 and 0x08000000
  • reads initial SP and reset handler as little-endian words
  • validates SRAM stack range
  • validates stack alignment
  • validates Thumb reset bit
  • checks whether reset target lands in loaded firmware
  • reports confidence score: none, low, medium, high

Added STM32-like fixture:

  • tests/fixtures/stm32_vector.ihex

Added tests:

  • test_entropy.c
  • test_vector_table.c

Covered known entropy values, heatmap symbols, high-confidence vector detection, missing-vector behavior, and an end-to-end STM32-like HEX sample.

Verification

Native GCC build passed with:

-std=c11 -Wall -Wextra -Wpedantic

Tests passed:

test_bin_loader: ok
test_entropy: ok
test_hex_parser: ok
test_memmap: ok
test_smoke: ok
test_vector_table: ok

Docker POSIX path passed:

make clean
make test
make

Current State

The MVP analysis path is now feature-complete for:

  • Intel HEX parsing
  • raw BIN loading
  • memory layout reconstruction
  • gap and overlap reporting
  • per-region entropy
  • chunk entropy
  • ASCII heatmap
  • Cortex-M vector table detection

Remaining stretch work includes JSON output, richer heuristics, section guessing, and comparison mode.

0
0
0
Open comments for this post

1h 5m 13s logged

Handling repos with large commit histories

This session focused on making gitscope stay responsive when opened in repositories with larger commit histories. The app now loads commit history incrementally instead of assuming the entire log can be fetched at startup.

What Changed

  • Added bounded commit loading with an initial page size.
  • Requested one extra commit per page so the UI can tell whether more history is available.
  • Added a manual “load more” action for extending the visible history.
  • Added automatic loading near the end of the currently loaded rows during keyboard navigation.
  • Added status bar feedback for loading, more-history, and end-of-history states.
  • Kept current branch/HEAD and all-branches views on the same paginated backend path.
  • Preserved selected-commit behavior as new pages are appended.

Why It Matters

Before this work, a very large repository could force the app to ask git for too much history up front. The updated behavior keeps startup bounded by the first page of commits, then loads additional pages only when the user asks for or navigates into them.

That keeps gitscope aligned with its core goal: a fast local read-only history viewer, not a heavyweight repository indexer.

Testing

Added and expanded tests around:

  • initial log loading staying bounded by page size
  • manual page loading appending rows
  • load-more stopping cleanly at the end of history
  • navigation near the loaded boundary requesting another page
  • all-branches loading using the same pagination window

Read-Only Review

The UI still does not call git directly. It asks the backend for paged commit data, selected-commit diffs, refs, and HEAD information only.

No checkout, staging, committing, branch mutation, remote operation, or network behavior was added.

Verification

  • py -m pytest passed with 31 tests.
  • Source installation continued to work.
  • The app could be mounted against the local gitscope repository with populated refs, log rows, selected commit, diff output, and status text.
0
0
0
Open comments for this post

37m 11s logged

Updates on the build!!

This session, I connected the earlier git data, diff parsing, and graph layout work to the Textual interface. gitscope now opens as a coordinated read-only history viewer instead of a static shell.

What Changed

  • Replaced the placeholder app screen with a real Textual layout.
  • Added a refs sidebar for HEAD, local branches, tags, and an all-branches view.
  • Added a commit table with graph, SHA, author, date, and subject columns.
  • Rendered the branch graph gutter from the pure graph layout module.
  • Added a diff pane that updates when the selected commit changes.
  • Added a compact diff overview strip beside the diff pane.
  • Added a status bar showing repo path, HEAD, selected ref, selected commit, loaded count, and key hints.
  • Added shared reactive state for the selected commit, so the log selection drives the diff pane cleanly.
  • Added key bindings for refresh, all branches, HEAD, load more, j/k movement, help, and quit.

Read-Only Behavior

The UI only asks the backend for repository data. It does not shell out to git directly and does not expose checkout, staging, committing, rebasing, pushing, pulling, fetching, branch creation, or any other mutating operation.

Selecting a branch or tag changes the viewed log data only. It does not change the checked-out branch.

Testing

Added headless Textual tests with a fake backend to verify:

  • the refs sidebar, commit table, diff pane, and status bar mount correctly
  • the selected commit updates the diff pane
  • moving the selection changes the displayed diff
  • selecting a ref reloads log data without mutating git state
  • the all-branches action uses the all-branches backend path

Verification

  • py -m pytest passed with 26 tests.
  • py -m pip install . completed successfully.
  • gitscope --version returned gitscope 0.1.0.
  • A headless app smoke check against the real gitscope repository loaded the commit log and selected the current commit.
  • Source scans confirmed subprocess access remains outside the UI.

Notes

The next devlog will cover large-repository behavior and release-readiness work.

0
0
0
Open comments for this post

27m 33s logged

Got basic stuff working!!

This session, I added the core non-UI logic behind gitscope: a read-only git data layer, a line-level diff parser, and a pure branch graph layout engine. The goal was to make the app capable of reading repository history while keeping git access, parsing, and graph computation testable outside the terminal UI.

Git Data Layer

Added a GitBackend abstraction around the local git binary. It is the only place application code should shell out to git.

The backend can now:

  • Discover the current repository root.
  • Validate that a path is inside a git work tree.
  • Report the repository path.
  • Read current HEAD details: full SHA, short SHA, and current branch.
  • List HEAD, local branches, and tags.
  • Load commit pages for HEAD or a specific ref.
  • Load commit pages across local branches.
  • Load the patch for a selected commit.

The backend deliberately stays read-only. It does not expose staging, committing, checkout, reset, merge, rebase, push, pull, fetch, clone, or branch mutation.

Data Models

Added typed records for the main data flowing through the app:

  • Commit
  • GitRef
  • HeadInfo
  • DiffLine
  • GraphRow
  • GraphCell
  • GraphConnection

These keep git output, parsed diffs, and graph layout results explicit instead of passing around loosely structured dictionaries or strings.

Diff Parsing

Added a pure parse_diff() function for line-level git diff output.

It classifies:

  • file headers
  • metadata lines
  • hunk headers
  • added lines
  • removed lines
  • context lines
  • no-newline markers

It also tracks old and new line numbers inside hunks so the UI can render a readable diff view later.

Graph Layout

Added a pure layout_graph() function that takes newest-first commits and parent SHAs, then returns lane and connector metadata for each row.

It handles:

  • empty history
  • root commits
  • linear history
  • merge commits
  • multiple active lanes
  • detached-style history

The graph logic is independent of Textual. It returns data that a terminal UI can render, but it does not depend on terminal widgets or screen state.

Testing

Added tests for:

  • backend command construction
  • backend parsing
  • unsafe refs and SHAs
  • unsupported git command shapes
  • non-work-tree validation
  • a real temporary git repository with commits, a branch, a tag, logs, refs, and diffs
  • diff classification and line numbering
  • empty diffs
  • root, linear, merge, multi-lane, and detached-style graph histories
  • graph collision checks

Verification

  • py -m pytest passed with 22 tests.
  • py -m pip install . completed successfully.
  • gitscope --version returned gitscope 0.1.0.
  • Source scans confirmed parser/layout/model modules do not depend on Textual, subprocess, or direct git commands.

Notes

  • Git access intentionally uses the installed git CLI rather than libgit2 bindings or direct object parsing.
  • The graph layout is a first practical implementation intended to be refined once it is exercised by the live UI.
  • Wiring this logic into the Textual interface is covered by the next devlog.
0
0
0
Open comments for this post

26m 4s logged

Established the project baseline for gitscope and completed the first foundation milestone. The repository now has planning documents, design guidance, installable Python package metadata, a starter Textual app shell, a console entry point, and an initial test layout.

Completed

  • Added project planning docs: README.md, PRD.md, AGENTS.md, and roadmap.md.
  • Added DESIGN.md and banner.png as the visual reference for the TUI.
  • Updated README.md to show the banner image.
  • Added pyproject.toml with Python package metadata, Textual dependency, console script, and pytest configuration.
  • Added the initial src/gitscope package with __init__.py, __main__.py, cli.py, and app.py.
  • Added a Milestone 1 Textual shell with the major design zones: title bar, refs sidebar, commit table, diff pane, status bar, and footer.
  • Added initial tests in tests/test_foundation.py.
  • Updated AGENTS.md to make following DESIGN.md compulsory for all TUI work.

Verification

  • py -m pip install . completed successfully.
  • gitscope --version returned gitscope 0.1.0.
  • py -m pytest passed with 3 tests.
  • A headless Textual mount smoke check completed successfully.

Notes

  • The current implementation is intentionally limited to Milestone 1 foundation work.
  • Git backend, graph layout, diff parsing, real refs, and live commit loading remain future milestone work.
  • On this machine, python resolves to an MSYS Python without pip, so verification used the working Windows launcher command py.
0
0
1
Ship Changes requested

envscope reached its first public release as a TUI-first `.env` inspection tool. The project started as planning documents and is now a packaged Python application with a full Textual interface, core comparison engine, PyPI distribution, and GitHub release binaries for Windows and Linux.

The v1.0 release detects:

- Missing keys declared in examples but absent from real env files.
- Extra keys present in real env files but undeclared in examples.
- Duplicate keys inside one file, preserving all line numbers.
- Empty-but-required values.
- Insecure values in both directions: real secrets leaked into example files and weak placeholder values left in real env files.

The app remains intentionally TUI-only. There are no CLI subcommands, CI mode, JSON output mode, daemon, or headless workflow in this version.

  • 3 devlogs
  • 4h
Try project → See source code →
Open comments for this post

2h 43m 19s logged

envscope reached its first public release as a TUI-first .env inspection tool. The project started as planning documents and is now a packaged Python application with a full Textual interface, core comparison engine, PyPI distribution, and GitHub release binaries for Windows and Linux.

What Shipped

The v1.0 release detects:

  • Missing keys declared in examples but absent from real env files.
  • Extra keys present in real env files but undeclared in examples.
  • Duplicate keys inside one file, preserving all line numbers.
  • Empty-but-required values.
  • Insecure values in both directions: real secrets leaked into example files and weak placeholder values left in real env files.

The app remains intentionally TUI-only. There are no CLI subcommands, CI mode, JSON output mode, daemon, or headless workflow in this version.

Product and UX

The interface was shaped around a developer diff dashboard: dark terminal styling, green/purple/blue accents, a file explorer picker, a scope list, candidate tabs, category counts, a diff table, and a selected-finding detail panel.

The picker now includes a file explorer. Selecting a directory updates the scan path, and selecting an .env* file uses its parent directory. Single-scope projects open directly into the diff view so simple projects like a root .env plus .env.example do not require extra navigation.

The diff view supports search, severity filtering, suppressed finding visibility, selected-finding details, and selected-only secret reveal. Secret-like values are masked by default throughout the TUI and export flow.

Core Engine

The core/ layer is UI-agnostic and independently tested. It contains:

  • A custom dotenv parser that preserves ordering, line numbers, duplicate entries, blank values, quotes, and export prefixes.
  • A scanner that discovers flat projects, multi-variant flat projects, and monorepo scopes.
  • A comparator that returns dataclass-based findings.
  • A data-driven heuristic engine for known token formats, high-entropy strings, weak values, and blank required secrets.

One important v1 fix was discovery behavior for gitignored env files. Many real projects list .env in .gitignore; envscope now still scans target .env files even when ordinary .gitignore rules mention them, while continuing to skip ignored directories such as .git, node_modules, venv, dist, and build.

Configuration

.envscope.toml supports:

  • Custom scan ignore globs.
  • Custom secret patterns.
  • Custom weak values.
  • Reasoned suppressions.

Suppressed findings are not deleted. They remain visible in the TUI and Markdown export, but are counted separately from active findings. Each suppression requires a reason.

Packaging and Release

The package was published to PyPI as envscope version 1.0.0.

Install command:

pip install envscope

PyPI page:

https://pypi.org/project/envscope/1.0.0/

GitHub release:

https://github.com/DevaanshPathak/envscope/releases/tag/v1.0.0

Release binaries:

  • envscope-windows-x86_64.exe
  • envscope-linux-x86_64

macOS binaries were intentionally skipped for this release. Building reliable macOS standalone binaries should be done on a macOS runner or macOS machine.

Verification

The final release passed:

uv run --extra dev pytest
uv run python -m compileall -q envscope tests
uv run python -m build
uv run python -m twine check dist/*

Test coverage includes parser behavior, scanner discovery, .gitignore handling, comparator categories, config parsing, suppressions, export formatting, heuristics, and a Textual smoke test.

0
0
3
Loading more…

Followers

Loading…