CodeAtlas — Codebase Inventory & Portfolio Engine

A tool that keeps an accurate inventory of a personal software estate across four drives, refreshed every night behind its own test suite, so every figure it reports can show its working.

A code inventory that will not quote a number it has not checked

Read the engineering notes See the dashboard

104,824lines of code
194files
287commits
2HTTP endpoints
51automated checks
3data models

The hard part

Counting code sounds easy until the count is wrong. One project first measured 27.5 million lines against about 95,000 of real source, because saved web pages, notebook outputs and backup folders all look like code to a simple count. A figure that wrong, stated confidently, is worse than no figure, and every resume or sales page built on it inherits the mistake.

Every folder is sorted into one of four kinds: source that was written, data the application takes in, output it generates, and duplicates of something counted elsewhere. Only source counts. A single read of each project feeds the dependency graph, the hotspot scores and the unused-code scan, so they cannot disagree about which files exist. The same measurements drive a nightly security sweep, answer AI agents in any project through MCP, a standard protocol for giving agents tools, and supply this portfolio's figures, which are quoted from measurements rather than typed from memory.

A 27.5 million-line count corrected to the real figure of about 95,000 by attributing each folder; three analyses that disagreed by almost 4,000 files now agree on 146 of 146 projects; every defect that shipped is recorded with the test that guards it.

What the measurements mean

Only what is unusual for this project. Every sentence names the field it came from; nothing here is asserted that cannot be checked against the data.

How it works

Counting code sounds simple, and that is the trap. A naive line count of one project here read 27.5 million lines; the real source was about 95,000. Saved web pages, notebook outputs and backup folders all look like code to a simple count. So CodeAtlas sorts every top-level folder into one of four kinds: source that was written, material the application takes in, output it generates, and duplicates of something counted elsewhere. Only the first kind counts as authored, and the page always shows what was set aside. When a measurement did not run, it says so and why, rather than showing a zero that looks like a fact. That habit of checking runs through the rest of it. The dependency graph, the complexity hotspots and the unused-code report all come from a single read of each project, so they cannot disagree about which files exist. It looks for credentials in the git history as well as the current files, and the value itself never leaves the scanning process. A read-only server lets AI agents working in any of my other projects query it directly, so they can find what already exists before writing something new. The same approach runs a security sweep across every Python environment on the machine. Installed packages are checked against public vulnerability data, including CISA's list of flaws being exploited in the wild, and ranked by what is running and reachable. Each fix is tested side by side against the old environment before it goes in. It also builds my resume, portfolio and public site from one set of career records, with a register that keeps employer figures off public pages and quotes figures about the estate from measurements rather than memory.

What it is built from

Each bar is one of this project's own modules, sized by how many times the rest of the project imports it. The counts are measured, not estimated, and the module at the top is the one the rest of the project leans on most.

Module mapInternal modules by how often they are imported: _console 102 times, _result 69 times, _atomic 27 times, _source 19 times, _cache 13 times, _git 12 times_console102_result69_atomic27_source19_cache13_git12events11career8gen_docs7_nested6tailor6claims5_venvs5grade5imports of each internal module, counted across the project

What kind of engineering this is

Six signals counted from the source: files that run models locally, that act without being asked each time, that check their own output, that survive failure, that touch parsers and protocols, and that were measured then improved. Every axis carries its file count.

Depth profileDepth signals: Local inference 24 files, Autonomy 29 files, Verification 44 files, Resilience 90 files, Low level 48 files, Iteration 0 filesLocal inference24 filesAutonomy29 filesVerification44 filesResilience90 filesLow level48 filesIteration0 files

What it is written in

Share of code bytes. Vendored bundles and generated output are set aside before this is computed, which is why it differs from a simple file count.

Language mixPython 77.1%, HTML 21.1%, CSS 0.7%, Batchfile 0.5%, PowerShell 0.4%, JavaScript 0.2%Python 77.1%HTML 21.1%

What stands out

Capabilities

Grade

Every check names the field it measured. Checks that cannot apply are excluded, never counted as failures.

A
100.0% over 18 of 18 checks100% coverage

Architecture

Directories carrying real modules, largest first.

HTTP surface

2 endpoints in total.

Data model

Typed structures and tables found in the source.

Vulnerable dependencies

2 declared dependencies match a published advisory. Checked offline against the OSV database; only pinned versions can be checked, so anything unpinned here is unknown rather than clean.

Vocabulary

Parsed 134 of 135 Python file(s); the rest were over the size budget. Counts are exact; the names below are a sample.

1,697functions
81methods
24classes
134documented modules

Classes

Functions

Command line

Depth

Signals counted from the code, not asserted.

286 commits across 39 separate working days over 2.9 months, 13 of them revising existing behaviour

Built from scratch

Closes its own loop

Proves itself

Survives failure

Local inference

Systems

Environment engineering

Distributed systems

Working within limits

Networking

GPU & memory management

Languages

Recurring themes in the commit history

Evidence

Taken from the code itself: a module docstring or the opening of the README.

Build the notes hub: a landing page for every write-up and playable build, and an anonymous portfolio -- no name, no contact, no employer, nothing that locates anyone. python hub/build.py write index.html and portfolio.html python hub/build.py --stage DIR also copy only the publishable files into DIR WHERE THINGS COME FROM. The projects, their words and their links are the portfolio's own payload

At a glance

Status
active
Primary language
Python
First commit
2026-08-17
Last activity
2026-11-12
Domain
Python projects
Agent docs
CLAUDE.md, AGENTS.md, .claude