Joseph Magly
b192577b54
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
135 lines
6.9 KiB
Markdown
135 lines
6.9 KiB
Markdown
# Option Matrix (Project Context and Intent)
|
|
|
|
**Purpose:** Capture what the project is and expose the decisions that owner input must complete.
|
|
**Generated:** 2026-07-20
|
|
|
|
## Project Reality
|
|
|
|
T3MP3ST is a mature, self-hosted TypeScript offensive-security platform with a local browser UI, CLI, HTTP API, MCP integration, external security-tool adapters, reproducible benchmarks, and extensive documentation. Its stable core operates real tools against authorized targets, while selected multi-agent, domain-specific, and evolutionary capabilities remain experimental or planned.
|
|
|
|
### Audience and Scale
|
|
|
|
| Attribute | Current evidence | Confidence |
|
|
| --- | --- | --- |
|
|
| Audience | Authorized operators, researchers, CTF users, developers, contributors | High |
|
|
| Distribution | Open-source package/repository, self-hosted execution | High |
|
|
| Active users/installations | Not measurable from the codebase | Unknown |
|
|
| Support expectations | Documentation and security-response target exist; no general SLA found | Medium |
|
|
| Geographic reach | Public open-source distribution implies global reach | Medium |
|
|
| Runtime concurrency | Local missions and agent/tool tasks; fleet scale unknown | Medium |
|
|
|
|
### Deployment and Infrastructure
|
|
|
|
| Attribute | Current state |
|
|
| --- | --- |
|
|
| Deployment model | Hybrid local application: CLI + browser UI/API + MCP + external tools |
|
|
| Hosting | Developer/operator workstation or Docker host; HTTP binds to loopback by default |
|
|
| Persistence | Local config, browser localStorage, reports, evidence, benchmark artifacts |
|
|
| Application database | None detected |
|
|
| CI/CD | GitHub Actions quality pipeline; no hosted-production deployment pipeline detected |
|
|
| Complexity | Modular monolith with many external integrations and high-risk execution boundaries |
|
|
|
|
### Technical Complexity
|
|
|
|
- Approximately 46,129 lines across 111 TypeScript files under `src/`
|
|
- 1,665 tracked files, dominated by committed JSON benchmark artifacts
|
|
- TypeScript primary; supporting JavaScript/MJS, shell, YAML, Python, C, Java, Go, Rust, Perl, HTML, and container definitions
|
|
- 75 test/spec-named files in `src/` and `scripts/`
|
|
- 52 Markdown documentation files across `docs/` and `docsite/`
|
|
- High-risk factors: real offensive operations, credentials, external tools, network access, sensitive evidence, model nondeterminism, multi-provider compatibility, and public benchmark claims
|
|
|
|
## Constraints and Context
|
|
|
|
### Known
|
|
|
|
- AGPL-3.0-or-later open-source licensing
|
|
- Node.js 18+ runtime and Node.js 22 CI
|
|
- Local-first/keyless operation is a core product promise
|
|
- Authorized use and target scope are non-negotiable safety constraints
|
|
- Claims are expected to be reproducible from committed evidence
|
|
- Stable versus experimental status must remain explicit
|
|
- The project supports a heterogeneous contributor base and multiple provider/runtime environments
|
|
|
|
### Unknown
|
|
|
|
- Maintainer availability and budget
|
|
- User/install base and growth targets
|
|
- Revenue or funding model
|
|
- Contractual obligations and general support SLA
|
|
- Formal compliance or certification objectives
|
|
- Release cadence and next milestone
|
|
- Current highest-priority pain point
|
|
|
|
## Priorities and Trade-offs
|
|
|
|
The codebase supports this provisional weighting, which must be validated by owners:
|
|
|
|
| Criterion | Provisional weight | Evidence-based rationale |
|
|
| --- | ---: | --- |
|
|
| Quality and security | 0.35 | Real offensive actions, secrets, evidence, authorization, and reputation risk |
|
|
| Reliability and scale | 0.25 | Mission orchestration and tool/model execution must fail safely; actual fleet scale is unknown |
|
|
| Delivery speed | 0.25 | Active roadmap and competitive research space favor iteration |
|
|
| Cost efficiency | 0.15 | Local/keyless operation is a product value, but maintainer budget is unknown |
|
|
| **Total** | **1.00** | Provisional only |
|
|
|
|
**Optimizing for:** Credible, reproducible offensive-security capability that remains safe-by-default and accessible through infrastructure users already possess.
|
|
|
|
**Likely acceptable trade-off:** Experimental capabilities may iterate before they are fully reliable if maturity is conspicuous and shared safety boundaries remain enforced.
|
|
|
|
**Non-negotiable:** Authorization, target containment, secret protection, evidence integrity, honest capability claims, and human control over disclosure or materially dangerous actions.
|
|
|
|
## Decision Options
|
|
|
|
| Option | Description | Benefits | Risks | Best fit |
|
|
| --- | --- | --- | --- | --- |
|
|
| A. Stabilize the core | Concentrate on existing stable paths, safety boundaries, docs, and release quality | Highest trust and lower regression surface | Slower domain expansion | Reliability or adoption is the immediate goal |
|
|
| B. Incremental expansion | Promote one experimental domain at a time using explicit benchmark and safety gates | Balanced learning and credibility | Requires disciplined promotion criteria | Default recommendation from code evidence |
|
|
| C. Swarm-first research | Prioritize multi-agent coordination and evolutionary capability | Differentiated research upside | Cost, nondeterminism, and safety complexity | Research funding and tolerance are explicit |
|
|
| D. Hosted/enterprise evolution | Add centralized service operations, tenancy, governance, and compliance | Broader organizational adoption | Major architecture and operating-model change | Real customer demand and resources exist |
|
|
|
|
## Framework Application
|
|
|
|
**Recommended now:**
|
|
|
|
- Full rigor for core safety, release, provenance, and claim-bearing paths
|
|
- Moderate rigor for experimental modules
|
|
- Architecture decisions for trust boundaries and maturity promotion
|
|
- Continuous security, architecture, risk, and test-strategy cycles
|
|
- Operational runbooks for local server, agent/provider failures, external tools, and sensitive artifacts
|
|
|
|
**Defer unless triggered:**
|
|
|
|
- Enterprise governance and formal change boards
|
|
- Hosted multi-tenant architecture
|
|
- Multi-region infrastructure and centralized observability
|
|
- Formal compliance certification work
|
|
|
|
**Adaptation triggers:**
|
|
|
|
- Hosted service or centrally retained user/target data
|
|
- Contractual SLA or regulated customer requirement
|
|
- Material growth in maintainers or release frequency
|
|
- Dangerous-tool surface expansion
|
|
- Experimental capability promoted to stable
|
|
- Public claims not fully covered by deterministic verification
|
|
- Significant user/install growth or recurring production incidents
|
|
|
|
## Owner Validation Needed
|
|
|
|
To finalize intent rather than infer it from code, owners should answer:
|
|
|
|
1. What decision or milestone triggered this intake?
|
|
Transition to AIWG memory system
|
|
|
|
2. Which matters most for the next release: stability, domain expansion, swarm research, or adoption?
|
|
all of the above
|
|
|
|
3. What is the current user/install scale and expected 12-month change?
|
|
thousands to tens of thousands
|
|
|
|
4. What failures would be unacceptable beyond the documented authorization constraints?
|
|
none, failsafe patterns always
|
|
|
|
5. Are there contractual, funding, compliance, or support commitments not represented in the repository?
|
|
no
|