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
This commit is contained in:
1 parent
937c6e9837
commit
b192577b54
28 files changed
+1076
No files matched your search
@@ -0,0 +1,80 @@
|
||||
# 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`
|
||||
|
||||
## Recommended Next Action
|
||||
|
||||
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.
|
||||
Reference in new issue
Block a user