Files
t3mp3st/.aiwg/intake/codebase-analysis-report.md
T
Joseph Magly b192577b54 docs(architecture): baseline current design (#109)
Capture the brownfield architecture and its relationship to the project vision.\n\n- add the current-state SAD and five retrospective ADRs\n- classify vision vectors against implementation evidence\n- record requirements, risks, gates, and construction handoff
2026-07-20 18:15:06 -04:00

4.2 KiB

Codebase Analysis Report

Project: T3MP3ST
Directory: /home/roctinam/dev/bt6/T3MP3ST
Generated: 2026-07-20
Revision: 186afe6b50e365371774aa2ed7986d73eb0656db

Summary

  • Tracked files: 1,665
  • Primary implementation: TypeScript/Node.js ESM
  • Source size: 111 TypeScript files and approximately 46,129 lines under src/
  • Test indicators: 75 test/spec-named files in src/ and scripts/
  • Documentation: 52 Markdown files in docs/ and docsite/
  • Architecture: Modular monolith with CLI, localhost web/API, MCP, model/provider, agent orchestration, tool adapters, evidence/reporting, and benchmark subsystems
  • Profile: Established open-source security product with stable core and explicitly experimental/research modules
  • Team signal: More than ten author identities and 151 commits in the last year; exact active human team size is unknown

Evidence-Based Inferences

High Confidence

  • T3MP3ST is an authorized-use offensive-security platform (README.md, SECURITY.md).
  • The runtime is Node.js/TypeScript and package version is 1.0.0 (package.json).
  • Users can operate through CLI, browser War Room/API, and MCP (package.json, src/, developer docs).
  • The server and Docker deployment bind to loopback by default (docs/DEVELOPER_GUIDE.md, docker-compose.yml).
  • The architecture is a modular monolith rather than microservices (src/ layout, one application image/service).
  • CI has extensive quality, provenance, claim, safety, and smoke gates (.github/workflows/ci.yml).
  • The repository uses committed benchmark corpora and deterministic claim verification (bench/, README, scripts).
  • Real offensive tools and sensitive artifacts make scope, approval, credentials, and evidence primary risk domains (SECURITY.md, src/arsenal/, Docker mounts).

Medium Confidence

  • The contributor community is medium-to-large for an open-source project, but aliases and automated-agent identities prevent an exact human team count.
  • The system is production-grade as a distributed open-source tool, while not necessarily operated as a production hosted service.
  • Reliability maturity is moderate: strong pre-release verification exists, but no hosted-service SLO/telemetry model is evident.
  • Security maturity is strong for the product category, but certification and organization-level controls cannot be inferred.

Unknown

  • Active users, installations, and workload volume
  • Maintainer staffing, funding, and availability
  • General support/on-call model
  • Formal contractual or regulatory obligations
  • Production incident rate and recovery objectives
  • Near-term product priority and deadline
  • Whether package repository metadata intentionally remains pointed at the upstream owner

Quality Assessment

Strengths

  • Clear stable/experimental/roadmap labeling
  • Strong verification culture and reproducible public claims
  • Extensive automated CI gates
  • Broad documentation for operators, developers, security, benchmarks, releases, and integrations
  • Localhost-first deployment and explicit authorization doctrine
  • Modular source organization and multiple integration surfaces
  • Private vulnerability-reporting process and response target

Risks and Weaknesses

  • Large capability surface and external-tool ecosystem amplify regression and supply-chain risk.
  • Stable and experimental code share core execution and brand surfaces.
  • Multi-agent/swarm reliability is less demonstrated than single-agent benchmark performance.
  • No formal workload/capacity baseline was found.
  • Sensitive artifacts rely heavily on operator-controlled local storage.
  • Repository ownership references differ between current tracker configuration and package.json.
  • Eighteen debt markers in implementation/script paths need owner triage.

Generated Files

  • .aiwg/intake/project-intake.md
  • .aiwg/intake/solution-profile.md
  • .aiwg/intake/option-matrix.md
  • .aiwg/intake/codebase-analysis-report.md

Have maintainers validate the five owner questions in option-matrix.md, then select incremental expansion, stabilization, research, or hosted evolution as the governing near-term path. The code evidence favors incremental expansion with explicit safety and benchmark promotion gates.