Tooling Roadmap
The tooling roadmap defines the practical shape of the public tool surface before additional utilities are added. It keeps tool growth aligned with the site’s security boundary: browser tools run locally, downloadable tools require release infrastructure, and validators enforce publication contracts. A tool should not be added because it is interesting. It should be added because it supports a repeatable research, review, or publication task.
The current emphasis is browser-local tooling. That keeps the first toolset inspectable and avoids asking users to upload evidence or install binaries before the release process is mature. Downloadable tooling remains part of the planned surface, but it requires checksums, signatures, release notes, versioning, and support boundaries before it becomes public.
Candidate Browser Tools
| Candidate | Purpose | Boundary |
|---|---|---|
| IOC Defanger/Refanger | Prepare indicators for reports without accidental activation | Text-only, local-only, no reputation lookup |
| URL Parser | Normalize and decompose URLs for review | No fetching, no DNS, no link preview |
| CSV Schema Profiler | Inspect columns, types, missing values, and delimiters | Local file only, no upload |
| YAML/JSON/TOML Converter | Convert structured configuration formats | Requires dependency review before YAML support |
| SBOM Viewer | Inspect CycloneDX or SPDX documents | Local parse only, no package lookup |
| Archive Directory Lister | Read central directory metadata without extraction | No decompression of file contents in first version |
| PE/ELF Header Viewer | Shallow binary metadata for triage notes | No disassembly, no emulation, no malware verdict |
Candidate Downloadable Tools
Downloadable tools should start with small validators or release helpers rather than complex scanners. A first downloadable release might package schema validators, report linting, or offline publication checks. Anything that inspects live systems, performs network activity, or processes untrusted binaries needs a separate review path and public documentation before release.
Acceptance Rule
A proposed tool needs a contract before code. The contract must state input types, output format, browser APIs used, storage behavior, network behavior, unsupported cases, and test fixtures. If those items cannot be written clearly, the tool is not ready to ship.