chore(aiwg): adopt shared BT6 maintainer workflow (#148)
* docs(policy): allow low-impact contributor courtesy cleanup * chore(aiwg): migrate to shared BT6 maintainer plugin * chore: reconcile delivery validation
This commit is contained in:
Joseph Magly authored and GitHub committed
1 parent
8f658891f2
commit
afc9dad1b2
89 files changed
+4683
-1512
No files matched your search
@@ -1,8 +1,8 @@
|
||||
# Codebase Analysis Report
|
||||
|
||||
**Project:** T3MP3ST
|
||||
**Directory:** `/home/roctinam/dev/bt6/T3MP3ST`
|
||||
**Generated:** 2026-07-20
|
||||
**Project:** T3MP3ST
|
||||
**Directory:** `/home/roctinam/dev/bt6/T3MP3ST`
|
||||
**Generated:** 2026-07-20
|
||||
**Revision:** `186afe6b50e365371774aa2ed7986d73eb0656db`
|
||||
|
||||
## Summary
|
||||
@@ -78,3 +78,23 @@
|
||||
## 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.
|
||||
|
||||
The owner subsequently selected a balanced priority across stability, domain expansion, swarm research, and adoption; supplied a scale estimate of thousands to tens of thousands; required fail-safe behavior; and reported no additional formal commitments. These are owner inputs, not measurements from the analyzed revision.
|
||||
|
||||
## Method and Limitations
|
||||
|
||||
Counts are point-in-time observations at the stated revision and command environment. File/test counts indicate surface area, not coverage or quality. Contributor identities are not normalized to humans. Architecture and maturity inferences are bounded by the cited files and were reconciled into the SAD and vision-alignment matrix.
|
||||
|
||||
## References
|
||||
|
||||
- @.aiwg/intake/project-intake.md — Detailed interpretation of the scan.
|
||||
- @.aiwg/intake/option-matrix.md — Owner answers recorded after analysis.
|
||||
- @.aiwg/architecture/software-architecture-doc.md — Architecture synthesis.
|
||||
- @package.json — Runtime, version, scripts, dependencies, and license.
|
||||
- @README.md — Product scope and claims.
|
||||
- @FEATURES.md — Capability/maturity inventory.
|
||||
- @SECURITY.md — Safety and disclosure policy.
|
||||
- @.github/workflows/ci.yml — CI implementation.
|
||||
- @src/cli.ts — CLI surface.
|
||||
- @src/server.ts — HTTP/War Room surface.
|
||||
- @src/mcp-server.ts — MCP surface.
|
||||
@@ -1,9 +1,12 @@
|
||||
# SDLC Accelerate Intake — T3MP3ST
|
||||
|
||||
**Entry mode:** Existing codebase
|
||||
**Baseline revision:** `186afe6b50e365371774aa2ed7986d73eb0656db`
|
||||
**Entry mode:** Existing codebase
|
||||
**Baseline revision:** `186afe6b50e365371774aa2ed7986d73eb0656db`
|
||||
**Guidance:** Capture architecture and design as current state, emphasize SAD/ADRs, and test alignment between `VISION.md` and implemented code.
|
||||
|
||||
**Owner:** Project maintainer / vision owner (name not recorded)
|
||||
**Stakeholders:** Authorized operators, researchers, maintainers, contributors, integrators, target owners, and finding recipients
|
||||
|
||||
## Problem Statement
|
||||
|
||||
Offensive-security capability is costly to assemble, difficult to coordinate, and easy to overstate. T3MP3ST provides a local-first orchestration platform that connects an operator's existing coding agent or model provider to scoped reconnaissance, exploitation, evidence, verification, and reporting workflows while retaining authorization and provenance controls.
|
||||
@@ -42,3 +45,34 @@ The implemented system is a TypeScript modular monolith with CLI, localhost War
|
||||
- Redesigning or implementing roadmap features
|
||||
- Claiming hosted-service scale, enterprise certification, or production SLOs without evidence
|
||||
- Treating `VISION.md` as an implemented specification
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
- Required merge/release checks include install/build, lint, typecheck, deterministic tests, coverage, doctor, claims, provenance, anti-fitting, prompt audit, and smoke according to the current workflow.
|
||||
- Critical scope, authorization, approval, exact-origin credential, and evidence/claim paths require negative tests and are release blocking.
|
||||
- Live target/provider tests are opt-in and separated from deterministic CI.
|
||||
- Repository-wide coverage is not inferred from file counts; critical-path cases and configured thresholds are authoritative.
|
||||
|
||||
## Data, Integrations, and Operations
|
||||
|
||||
- **Data classification:** Public source/docs; internal configuration/mission state; confidential or restricted credentials, target data, evidence, findings, and disclosure material.
|
||||
- **External integrations:** Hosted/local reasoning providers, authenticated coding-agent CLIs, MCP clients, security tools, authorized targets, GitHub CI/collaboration, and documentation publishing.
|
||||
- **Operations:** Local/self-hosted Node or Docker process; no hosted service SLO, general on-call model, or centralized telemetry is claimed.
|
||||
|
||||
## Owner-Validated Context
|
||||
|
||||
- Near-term priority includes stability, domain expansion, swarm research, and adoption; iteration plans must balance them through explicit evidence and safety gates.
|
||||
- Reported scale expectation is thousands to tens of thousands of users/installations; it is owner-provided planning context, not repository telemetry.
|
||||
- No additional contractual, funding, compliance, or support commitments were supplied.
|
||||
- Failure behavior must be fail-safe; this does not mean all failures are acceptable or that safety/evidence defects can be waived.
|
||||
|
||||
## References
|
||||
|
||||
- @.aiwg/intake/project-intake.md — Detailed brownfield intake.
|
||||
- @.aiwg/intake/option-matrix.md — Owner-validated intent and trade-offs.
|
||||
- @.aiwg/intake/risk-screening.md — Initial risk register.
|
||||
- @.aiwg/requirements/nfr-register.md — Measurable quality constraints.
|
||||
- @.aiwg/testing/test-strategy.md — Test levels and gates.
|
||||
- @README.md — Product scope and claims.
|
||||
- @SECURITY.md — Authorization, safety, and reporting policy.
|
||||
- @package.json — Runtime, package, and license metadata.
|
||||
@@ -1,6 +1,6 @@
|
||||
# Option Matrix (Project Context and Intent)
|
||||
|
||||
**Purpose:** Capture what the project is and expose the decisions that owner input must complete.
|
||||
**Purpose:** Capture what the project is and expose the decisions that owner input must complete.
|
||||
**Generated:** 2026-07-20
|
||||
|
||||
## Project Reality
|
||||
@@ -13,7 +13,7 @@ T3MP3ST is a mature, self-hosted TypeScript offensive-security platform with a l
|
||||
| --- | --- | --- |
|
||||
| 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 |
|
||||
| Active users/installations | Owner reports thousands to tens of thousands; no repository telemetry verifies the count | Owner input / unmeasured |
|
||||
| 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 |
|
||||
@@ -50,10 +50,10 @@ T3MP3ST is a mature, self-hosted TypeScript offensive-security platform with a l
|
||||
- Stable versus experimental status must remain explicit
|
||||
- The project supports a heterogeneous contributor base and multiple provider/runtime environments
|
||||
|
||||
### Unknown
|
||||
### Unknown or Unverified
|
||||
|
||||
- Maintainer availability and budget
|
||||
- User/install base and growth targets
|
||||
- Measured user/install telemetry and observed growth rate
|
||||
- Revenue or funding model
|
||||
- Contractual obligations and general support SLA
|
||||
- Formal compliance or certification objectives
|
||||
@@ -132,3 +132,21 @@ none, failsafe patterns always
|
||||
|
||||
5. Are there contractual, funding, compliance, or support commitments not represented in the repository?
|
||||
no
|
||||
|
||||
## Decision Record
|
||||
|
||||
- **Selected posture:** Balanced portfolio across stability, incremental domain expansion, swarm research, and adoption.
|
||||
- **Governing constraint:** Fail-safe behavior; authorization, scope, secrets, evidence integrity, and honest claims remain non-negotiable.
|
||||
- **Scale input:** Thousands to tens of thousands of users/installations, treated as owner-supplied planning context until telemetry supports a measured claim.
|
||||
- **Commitments:** No additional contractual, funding, compliance, or support commitments supplied.
|
||||
- **Architecture effect:** Continue local-first modular baseline; hosted/distributed work requires a new decision rather than inference from adoption goals.
|
||||
|
||||
## References
|
||||
|
||||
- @.aiwg/intake/project-intake.md — Detailed codebase-derived context.
|
||||
- @.aiwg/intake/solution-profile.md — Recommended rigor and roadmap.
|
||||
- @.aiwg/intake/risk-screening.md — Non-negotiable risk constraints.
|
||||
- @.aiwg/architecture/adr-005.md — Maturity/current-state policy.
|
||||
- @.aiwg/planning/iteration-001-plan.md — Near-term balanced governance work.
|
||||
- @README.md — Public product scope.
|
||||
- @VISION.md — Research direction.
|
||||
@@ -1,7 +1,7 @@
|
||||
# Project Intake Form (Existing System)
|
||||
|
||||
**Document type:** Brownfield system documentation
|
||||
**Generated:** 2026-07-20
|
||||
**Document type:** Brownfield system documentation
|
||||
**Generated:** 2026-07-20
|
||||
**Source:** Codebase analysis of `/home/roctinam/dev/bt6/T3MP3ST`
|
||||
|
||||
## Metadata
|
||||
@@ -27,7 +27,7 @@ T3MP3ST is a self-hosted, multi-agent offensive-security framework for authorize
|
||||
- Developers integrating security workflows through HTTP or MCP
|
||||
- Contributors extending operators, tools, benchmarks, and target adapters
|
||||
|
||||
Actual installation count, active-user count, commercial use, support commitments, and production fleet size are **unknown**.
|
||||
The owner reports a current/expected scale of thousands to tens of thousands of users or installations. This is planning input rather than measured repository telemetry. Commercial use, support commitments, and production fleet topology remain unverified; the owner supplied no additional contractual, funding, compliance, or support commitments.
|
||||
|
||||
## Current Scope and Features
|
||||
|
||||
@@ -89,7 +89,7 @@ Performance-sensitive areas include:
|
||||
- Concurrent agent/operator orchestration
|
||||
- Benchmark corpus processing
|
||||
|
||||
Exact throughput, concurrent-user capacity, p95 latency, resource profiles, and installation scale are unknown. Existing timeout controls and deterministic benchmark harnesses provide a foundation for measuring these characteristics.
|
||||
Exact throughput, concurrent-task capacity, p95 latency, and resource profiles are unknown. Installation/user scale is owner-estimated rather than measured. Existing timeout controls and deterministic benchmark harnesses provide a foundation for measuring these characteristics.
|
||||
|
||||
## Security, Safety, and Compliance
|
||||
|
||||
@@ -152,9 +152,8 @@ No Kubernetes, Terraform, service mesh, managed database, centralized cache, or
|
||||
|
||||
The invocation supplied no additional business guidance. The evidenced purpose is to establish a current SDLC baseline from the existing codebase, preserve the distinction between shipped and aspirational capabilities, and provide a reviewable starting point for requirements, architecture, risk, and roadmap decisions.
|
||||
|
||||
## Unknowns Requiring Owner Validation
|
||||
## Owner-Validated Context and Remaining Unknowns
|
||||
|
||||
- Current active installations and users
|
||||
- Maintainer roles, staffing, and support model
|
||||
- Funding or commercial model
|
||||
- Production usage patterns and capacity objectives
|
||||
@@ -162,9 +161,39 @@ The invocation supplied no additional business guidance. The evidenced purpose i
|
||||
- Regulatory or contractual obligations of maintainers
|
||||
- Near-term milestone, roadmap priority, and desired investment trade-offs
|
||||
|
||||
Owner input recorded in `option-matrix.md`: scale is thousands to tens of thousands; stability, expansion, swarm research, and adoption all matter; no extra formal commitments were supplied; execution should fail safely.
|
||||
|
||||
## Testing Strategy and Quality Thresholds
|
||||
|
||||
- Required CI/release gates are defined in the test strategy and workflow; all required gates must pass for the release revision.
|
||||
- Scope, authorization, approval, credential routing, evidence integrity, and claim reproduction are critical paths with non-negotiable negative tests.
|
||||
- Deterministic CI uses fixtures and committed evidence rather than live target or paid-model availability.
|
||||
- Performance claims require workload, environment, sample, percentile, and receipt; no unmeasured SLO is accepted.
|
||||
|
||||
## Decision Heuristics
|
||||
|
||||
- Prefer local simplicity over distributed power until an evidenced deployment need justifies a new baseline.
|
||||
- Prefer operator control and fail-safe refusal over automatic execution when authorization or scope is ambiguous.
|
||||
- Prefer reproducible, scoped claims over broader marketing language.
|
||||
- Priority weighting remains quality/security 0.35, reliability/scale 0.25, delivery speed 0.25, cost 0.15 until owners amend it.
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. Validate the unknowns above with project owners.
|
||||
2. Review the recommended rigor and roadmap in `solution-profile.md`.
|
||||
3. Confirm priorities and trade-offs in `option-matrix.md`.
|
||||
4. If accepted, use the intake as input to an Inception or continuous architecture/risk workflow. `intake-start` is not required for this generated intake.
|
||||
|
||||
## References
|
||||
|
||||
- @.aiwg/intake/intake-form.md — Concise accelerate intake and owner-validated context.
|
||||
- @.aiwg/intake/solution-profile.md — Tailored rigor and roadmap.
|
||||
- @.aiwg/intake/option-matrix.md — Trade-offs and recorded owner answers.
|
||||
- @.aiwg/intake/risk-screening.md — Initial risks and residual exposure.
|
||||
- @.aiwg/architecture/software-architecture-doc.md — Implemented architecture baseline.
|
||||
- @.aiwg/testing/test-strategy.md — Required testing and gate policy.
|
||||
- @README.md — Product scope and maturity claims.
|
||||
- @FEATURES.md — Feature inventory.
|
||||
- @SECURITY.md — Safety and vulnerability-reporting policy.
|
||||
- @package.json — Package/runtime/license source.
|
||||
- @.github/workflows/ci.yml — CI evidence.
|
||||
@@ -1,13 +1,45 @@
|
||||
# Initial Risk Screening
|
||||
# Initial Risk Register
|
||||
|
||||
| ID | Risk | Severity | Evidence | Mitigation / control | Status |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| R-01 | Operations exceed authorized target scope | Critical | Real network/exploitation tools | Target scope model, egress containment, approvals, scope receipts | Controlled; continuous verification |
|
||||
| R-02 | Secrets or engagement evidence leak | High | Provider keys, target headers, reports/evidence | Environment variables, target-origin binding, protected paths, local storage guidance | Open residual risk |
|
||||
| R-03 | Aspirational capability is represented as shipped | High | Broad `VISION.md`; mixed maturity surface | Status labels, claim verifier, vision-alignment matrix | Controlled; governance required |
|
||||
| R-04 | Model/tool nondeterminism produces false findings | High | LLM and external-tool execution | Ground-truth grading, finding verification, refuter/provenance gates | Open residual risk |
|
||||
| R-05 | External tools or dependencies compromise host/supply chain | High | Arsenal and container/tool installation | Narrow adapters, approval paths, pinned CI actions, isolated execution guidance | Open |
|
||||
| R-06 | Modular monolith accumulates unsafe coupling | Medium | Broad `src/` domain surface | Module boundaries, SAD, ADRs, architecture checks | Open |
|
||||
| R-07 | Local artifact loss or retention mishandling | Medium | Filesystem reports/evidence and browser localStorage | Protected update paths and operator procedures | Open |
|
||||
## Metadata and Method
|
||||
|
||||
No risk makes the documented current solution infeasible. R-01 is blocking for any release that weakens default containment without an approved replacement control.
|
||||
- **Owner:** Project manager / safety steward (named assignee pending)
|
||||
- **Review cadence:** Each iteration, release, trust-boundary change, public claim change, or serious defect
|
||||
- **Scale:** Impact and likelihood use Critical/High/Medium/Low; exposure reflects pre-control combination; residual risk reflects current controls and evidence.
|
||||
- **Blocking rule:** Any change that weakens authorization, default scope containment, exact-origin credentials, or required evidence/claim gates without an approved replacement control blocks release.
|
||||
|
||||
## Prioritized Risks
|
||||
|
||||
| ID | Description | Impact | Likelihood | Exposure | Mitigation / control | Owner role | Status | Residual risk |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| R-001 | Operations exceed authorized target scope | Critical | Medium | Critical | Explicit target/RoE, scope gate, approval, adapter negative tests, release blocking | Safety reviewer | Mitigating continuously | Medium; adapter completeness must remain verified |
|
||||
| R-002 | Provider/target secrets or engagement evidence leak | Critical | Medium | Critical | Environment/local config, exact-origin headers, redaction, ignored/protected paths, operator retention | Safety + release | Open residual | Medium; local host/storage policy remains operator-controlled |
|
||||
| R-003 | Aspirational or corpus-scoped capability is represented as generally stable | High | High | High | ADR-004/005, maturity matrix, claim/stub/count tests, planned consistency audit | Evaluation steward | Mitigating | Medium until automated cross-doc audit exists |
|
||||
| R-004 | Model/tool nondeterminism produces a false finding | High | High | High | Evidence gate, adjudication, verification/refutation, receipts and report state | Evaluation + safety | Open residual | Medium; live evidence can remain incomplete |
|
||||
| R-005 | External tool/dependency compromises host or supply chain | Critical | Medium | Critical | Narrow structured adapters, approvals, container guidance, lockfile/CI review, future SBOM/signing decision | Configuration manager | Open | Medium/High depending on selected tool |
|
||||
| R-006 | Modular monolith accumulates unsafe coupling | High | Medium | High | Typed seams, shared safety controls, SAD/ADRs, tests, architecture review triggers | Architecture steward | Mitigating | Medium |
|
||||
| R-007 | Local artifact loss, corruption, or retention mishandling | High | Medium | High | Protected update paths, local mounts, operator backup/retention, rollback plan | Operator + release | Open | Medium; no centralized durability claim |
|
||||
| R-008 | Imported code/target content or model output manipulates the agent/runtime | Critical | Medium | Critical | Treat content as untrusted, deterministic execution gates, bounded parsers, prompt audit, evidence verification | Safety reviewer | Mitigating | Medium; evolving agentic attacks require review |
|
||||
| R-009 | Provider/tool timeout or infrastructure failure is reported as success/model failure | High | Medium | High | Finite timeouts, explicit error classification, fallback records, receipt outcome taxonomy | Test/evaluation | Mitigating | Low/Medium |
|
||||
| R-010 | Unknown ownership/capacity delays critical review or response | High | Medium | High | Assign role owners per iteration/release; named approvals and backup reviewers | Maintainer | Open | High until roster assigned |
|
||||
|
||||
## Review Actions
|
||||
|
||||
1. Complete the machine-readable network-adapter safety/test inventory for R-001 and R-005.
|
||||
2. Implement cross-document maturity consistency for R-003.
|
||||
3. Define sensitive-artifact backup, retention, encryption, and disposal guidance for R-002/R-007.
|
||||
4. Assign named architecture, safety, evaluation, test, and release owners for R-010.
|
||||
5. Re-score after Iteration 001 evidence is available; do not mark residual risk “Low” without a cited test/control result.
|
||||
|
||||
## References
|
||||
|
||||
- @.aiwg/requirements/nfr-register.md — Risk-linked quality constraints.
|
||||
- @.aiwg/architecture/adr-003.md — Scope/approval/credential control decision.
|
||||
- @.aiwg/architecture/adr-004.md — Evidence and claim decision.
|
||||
- @.aiwg/architecture/adr-005.md — Maturity claim decision.
|
||||
- @.aiwg/architecture/software-architecture-doc.md — Trust boundaries and residual questions.
|
||||
- @.aiwg/testing/test-strategy.md — Verification and release-blocking policy.
|
||||
- @.aiwg/team/team-profile.md — Ownership gaps and handoff rules.
|
||||
- @SECURITY.md — Authorized use and vulnerability reporting.
|
||||
- @src/__tests__/arsenal-scope-gate.test.ts — R-001 control evidence.
|
||||
- @src/__tests__/target-headers-static.test.ts — R-002 control evidence.
|
||||
- @scripts/verify-claims.mjs — R-003 control evidence.
|
||||
@@ -1,6 +1,6 @@
|
||||
# Solution Profile (Current System)
|
||||
|
||||
**Document type:** Existing system profile
|
||||
**Document type:** Existing system profile
|
||||
**Generated:** 2026-07-20
|
||||
|
||||
## Current Profile
|
||||
@@ -107,3 +107,24 @@ Lower-value components until owner context changes:
|
||||
- Database migration plans for an application database that does not currently exist
|
||||
|
||||
Revisit those exclusions if the project becomes a hosted service, assumes contractual SLAs, processes centrally retained customer data, or grows into a larger formal organization.
|
||||
|
||||
## Decision Criteria and Verification
|
||||
|
||||
| Profile claim | Evidence required to retain classification |
|
||||
| --- | --- |
|
||||
| Stable core | Supported operational path, deterministic critical tests, maintained docs, release gate |
|
||||
| Experimental subsystem | Explicit label, bounded safety controls, test scope, limitations, no stable SLA implication |
|
||||
| Strong testing | Current required CI passes; critical path mapping is complete; no metric inferred from file counts |
|
||||
| Moderate reliability | Health/timeout/smoke evidence exists while hosted SLO/telemetry claims remain absent |
|
||||
| Strong product safety | Scope/approval/origin negative tests pass and adapter inventory has no uncovered path |
|
||||
|
||||
## References
|
||||
|
||||
- @.aiwg/intake/project-intake.md — Brownfield evidence and constraints.
|
||||
- @.aiwg/intake/option-matrix.md — Owner priorities and scale context.
|
||||
- @.aiwg/intake/risk-screening.md — Risk exposure and controls.
|
||||
- @.aiwg/requirements/nfr-register.md — Measurable quality attributes.
|
||||
- @.aiwg/architecture/software-architecture-doc.md — Current-state architecture.
|
||||
- @.aiwg/architecture/vision-alignment.md — Maturity classification.
|
||||
- @.aiwg/testing/test-strategy.md — Testing profile evidence.
|
||||
- @.github/workflows/ci.yml — CI implementation.
|
||||
Reference in new issue
Block a user