π Day 156 β Too Many Projects: Auditing My Own Tool Sprawl Like an Asset Inventory
π Topic
I reached the point where I honestly did not know what I had anymore: too many projects, apps, agents, and half-finished experiments. So I ran a βwhat is going onβ audit across the whole workstation.
π― Goal
Build an accurate inventory of every project and agent, decide what stays active, what gets archived, and leave behind documentation that a tired, non-technical version of me can follow.
π What I Did
I audited the full stack instead of starting anything new.
Main areas covered:
- inventoried every project, app, and agent on the machine and judged each one against my current goals
- audited the
robintool and decided whether it earns its place or gets archived as a niche experiment - inspected the old OpenClaw workspace, migrated the few useful pieces, and prepared an archive plan for the rest
- ran live self-tests against each agent path to prove what actually responds versus what only exists in docs
- produced a full agent-stack audit report with the self-test artifacts saved as evidence
- wrote a canonical START-HERE entry point, a docs INDEX, and a one-page daily-start guide for non-technical me
π Key Cybersecurity Connections
This is asset inventory, the first control on basically every security framework list. You cannot secure, patch, or monitor what you do not know you have. Forgotten tools with real capabilities are exactly how shadow IT happens β I was doing it to myself, one abandoned agent at a time.
Decommissioning matters too: an archived project with revoked capabilities is safe; a forgotten project with live credentials is a liability.
π Investigation Questions
- What is actually installed, running, or reachable on this machine?
- Which agents have capabilities granted that nothing currently uses?
- What proves a component works β documentation, or a live test?
- Which projects are superseded and safe to archive?
- Could someone else (or future me) find the entry point without asking?
π¨ Detection Opportunities
Useful checks for tool sprawl:
- services or agents responding that appear in no inventory
- projects untouched for months but still holding credentials or access
- self-test failures on components the docs claim are active
- duplicate tools doing the same job with different security postures
- archives that still have live endpoints or scheduled jobs
Example:
project=workstation-inventory
signal=active_agent_missing_from_inventory
risk_area=unmanaged_capability
triage=self_test_then_inventory_or_decommission
π§ MITRE ATT&CK Techniques
No direct mapping claimed. This is asset management and attack-surface reduction for my own environment.
πΊ Visual Investigation Diagram
"What do I even have?"
β
Inventory everything
β
Live self-tests as evidence
β
Keep / archive decision per item
β
START-HERE + INDEX + daily guide
β
Smaller, known, documented surface
β Challenges
The hard part was emotional, not technical. Archiving a project feels like admitting the time was wasted. It was not β but keeping every experiment alive βjust in caseβ is how the surface got unmanageable.
π What I Learned
I learned that an inventory built from live tests is worth ten built from memory. Several things I βknewβ were working did not respond, and one thing I had forgotten entirely was still capable of acting.
β‘ Next Steps
- Execute the OpenClaw archive plan
- Keep START-HERE as the single canonical entry point
- Re-run the agent self-tests periodically, not just once
- Apply the same keep/archive discipline before starting new projects
π§ Reflection
Auditing my own sprawl felt like doing a client engagement on myself. The findings were familiar from theory: unknown assets, stale access, missing documentation. Living them is different.
π§© Lessons Learned
What worked
Live self-tests as the source of truth instead of documentation.
What broke
My mental model of what was running β it was wrong in both directions.
Why it broke
Months of fast experimentation with no inventory discipline.
Fix / takeaway
Inventory first, then decide. Archive without guilt; document without exceptions.
π Skill Progression Context
This supports my cybersecurity progression because asset inventory, evidence-based verification, and decommissioning are foundational defensive skills β practiced here on a real, messy environment I own.
π TL;DR
Audited my own shadow IT; the attacker was me, the defense was a list.
