pentesting 0.101.7 → 0.101.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +7 -1
- package/package.json +2 -3
- package/ARCHITECTURE.md +0 -622
package/README.md
CHANGED
|
@@ -54,7 +54,7 @@ Provider variables are optional — the TUI launches without them and lets you l
|
|
|
54
54
|
| Verified agent loop | Streams actions and observations; a model Stop ends only the turn, evidence-backed verification closes the mission, and the full trajectory is persisted |
|
|
55
55
|
| Unified tool boundary | Built-in, delegated, and MCP calls share schema validation, provenance, permissions, policy, and resource limits |
|
|
56
56
|
| Context economy | Automatic micro-pruning and model-triggered summaries preserve useful context for low-cost models |
|
|
57
|
-
| Deterministic steering | Esc stops the current turn and auto loop
|
|
57
|
+
| Deterministic steering | Active-turn submissions are retained for the next safe transcript boundary; Esc stops the current turn and auto loop while the visible inputs resume in FIFO order |
|
|
58
58
|
| Reverse-shell & PTY lifecycle | One control plane manages authorized callbacks and local PTY/pipe sessions, from tagging, probing, and verified upgrades to transcripts, evidence, FD accounting, and deterministic reclamation |
|
|
59
59
|
| Bounded battlefield | A persistent Lead ledger produces a compact on-demand attention brief and read-only `/status` view; dispatch stays explicit and is capped at four branches |
|
|
60
60
|
| Adversarial pathfinding | A localized AlphaGo-inspired minimax technique models an opponent's best defensive move and improves the ability to find viable bypass paths |
|
|
@@ -115,3 +115,9 @@ Provider variables are optional — the TUI launches without them and lets you l
|
|
|
115
115
|
> Each voice sings its most beautiful song from its own place, yet when combined, they create one grand, beautiful melody. I believe this structure is no different from AI agents.
|
|
116
116
|
>
|
|
117
117
|
> — *agnusdei1207*
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
## 💡 Insight
|
|
122
|
+
|
|
123
|
+
> Analyzing countless starred agent repos and papers gave me insights, but adopting them didn't actually solve the core problem. What did, I think: primitive CS theory — backtracking, Monte Carlo, Prim, Kruskal — and ideas from observing myself, the best design blueprint and best practice there is. The AI era keeps pushing sensational marketing, and I've lost trust in analyzing it. I think refining the fundamentals, internalizing them, and finding my own way matters more, especially now.
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "pentesting",
|
|
3
|
-
"version": "0.101.
|
|
4
|
-
"builderReleaseTag": "v0.101.
|
|
3
|
+
"version": "0.101.9",
|
|
4
|
+
"builderReleaseTag": "v0.101.9",
|
|
5
5
|
"description": "Penetration testing AI agent powered by Rust, with audited reverse-shell capture, verified PTY upgrades, and evidence-first orchestration.",
|
|
6
6
|
"license": "MIT",
|
|
7
7
|
"author": "agnusdei1207",
|
|
@@ -14,7 +14,6 @@
|
|
|
14
14
|
"lib",
|
|
15
15
|
"scripts/postinstall.mjs",
|
|
16
16
|
"README.md",
|
|
17
|
-
"ARCHITECTURE.md",
|
|
18
17
|
"pentesting-logo.svg"
|
|
19
18
|
],
|
|
20
19
|
"engines": {
|
package/ARCHITECTURE.md
DELETED
|
@@ -1,622 +0,0 @@
|
|
|
1
|
-
# Architecture
|
|
2
|
-
|
|
3
|
-
This document reflects the current `main` branch architecture. It is the single,
|
|
4
|
-
detailed reference for how the runtime is structured; the [README](README.md)
|
|
5
|
-
stays intentionally short and usage-focused.
|
|
6
|
-
|
|
7
|
-
> **Engine vs product.** The orchestration engine is **`builder`** — a
|
|
8
|
-
> general-purpose, local-first Rust agent runtime. **`pentesting`** is the
|
|
9
|
-
> published, security-focused distribution of that same engine: the npm package
|
|
10
|
-
> and the command you run. They share one binary. The model owns task reasoning;
|
|
11
|
-
> the Rust runtime owns protocol normalization, authorization, bounded execution,
|
|
12
|
-
> observations, and verified outcome provenance.
|
|
13
|
-
|
|
14
|
-
## 1. Architecture at a glance
|
|
15
|
-
|
|
16
|
-
```text
|
|
17
|
-
user input
|
|
18
|
-
→ deterministic turn queue
|
|
19
|
-
→ model/provider adapter
|
|
20
|
-
→ one tool gateway
|
|
21
|
-
→ authorized, bounded execution
|
|
22
|
-
→ append observation to the turn
|
|
23
|
-
→ repeat until TurnExit
|
|
24
|
-
→ emit TurnCompleted
|
|
25
|
-
→ emit TaskComplete only for a verified MissionState
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
The core is deliberately narrower than the complete product. Its append-only
|
|
29
|
-
`TurnEvent` trajectory contains model terminals, actions, observations, and
|
|
30
|
-
verification provenance. The complete trajectory is stored in the terminal
|
|
31
|
-
`RunOutcome`; the request-time `TurnSnapshot` is its bounded O(1) projection.
|
|
32
|
-
Memory, MCP,
|
|
33
|
-
delegation, CTF exploration, and security sessions use the same tool boundary.
|
|
34
|
-
Engagement context changes instructions, not tool reachability; resource caps
|
|
35
|
-
bound expensive operations.
|
|
36
|
-
|
|
37
|
-
## 2. Design pillars
|
|
38
|
-
|
|
39
|
-
- **Model-Driven Work** — The model chooses plans, probes, commands, and ordinary
|
|
40
|
-
recovery. The runtime does not duplicate that reasoning with hot-path LLM judges.
|
|
41
|
-
- **Hard Boundaries, Not Hard Opinions** — Schema, scope, permission, secrets,
|
|
42
|
-
cancellation, time, output, memory, and process limits are deterministic.
|
|
43
|
-
- **Typed Turn Lifecycle** — Provider terminal state, `TurnExit`, and
|
|
44
|
-
`MissionState` are separate. Stop is never proof of success.
|
|
45
|
-
- **One Tool Entry Boundary** — Built-in, delegated, and MCP tools share
|
|
46
|
-
allowlist, provenance, registered-contract, and schema validation. Hooks are
|
|
47
|
-
orchestrator-owned; permission checks apply only when a tool produces a
|
|
48
|
-
policy operation. Ordinary/MCP tools use configured timeouts, while
|
|
49
|
-
delegation uses its own runtime budget.
|
|
50
|
-
- **Append-Oriented Observation** — Trajectory and evidence are local-first;
|
|
51
|
-
prior-run information is linked by reference rather than copied.
|
|
52
|
-
- **Deterministic Queuing** — FIFO revisions support amend-next and explicit
|
|
53
|
-
replace without auxiliary LLM prioritization.
|
|
54
|
-
- **One Security Surface** — Session, process, finding, flag verification, and
|
|
55
|
-
frontier operations are ordinary tools. Engagement context, permission,
|
|
56
|
-
resource budget, and proof remain separate responsibilities.
|
|
57
|
-
- **Prompt Ownership** — Prompt mode owns Enter submission. Buffered replay may
|
|
58
|
-
preserve typed-ahead input, but live terminal control responses, redraws, and
|
|
59
|
-
resize noise are not allowed to turn a normal Enter into a pasted newline.
|
|
60
|
-
Modal return restores the transcript scroll region and its pre-modal saved
|
|
61
|
-
cursor before the fixed bottom UI is redrawn.
|
|
62
|
-
- **Lab Session Multiplexing** — `shell-listener` runs multiple authorized TCP,
|
|
63
|
-
local PTY, and local pipe sessions. A single actor exclusively owns each
|
|
64
|
-
session's descriptors, command queue, transcript, raw log, and child
|
|
65
|
-
lifecycle; the registry keeps only a bounded sender and projection.
|
|
66
|
-
- **Ebbinghaus-Inspired Memory** — Memories carry a *strength* that fades like
|
|
67
|
-
human memory and reinforces on recall. Faded notes are de-referenced, never
|
|
68
|
-
destroyed.
|
|
69
|
-
- **Git-Backed Rewind** — Working-tree checkpoint/restore keeps autonomous edits
|
|
70
|
-
reversible.
|
|
71
|
-
|
|
72
|
-
## 3. Runtime flow, one level deeper
|
|
73
|
-
|
|
74
|
-
```mermaid
|
|
75
|
-
flowchart TD
|
|
76
|
-
U[User request] --> CLI[builder_main CLI / TUI]
|
|
77
|
-
CLI --> API[builder_api facade]
|
|
78
|
-
API --> APP[builder_app coordination]
|
|
79
|
-
APP --> TURN[Turn kernel]
|
|
80
|
-
TURN --> MODEL[Provider adapter]
|
|
81
|
-
MODEL --> GW[Tool entry boundary]
|
|
82
|
-
GW --> POLICY[Schema + applicable policy/resource boundary]
|
|
83
|
-
POLICY --> EXEC[Tool / environment execution]
|
|
84
|
-
EXEC --> OBS[Observation + artifact refs]
|
|
85
|
-
OBS --> TURN
|
|
86
|
-
TURN --> EXIT[Typed TurnExit]
|
|
87
|
-
EXIT --> VERIFY[Outcome verifier]
|
|
88
|
-
VERIFY --> OUT[TurnCompleted / verified TaskComplete]
|
|
89
|
-
```
|
|
90
|
-
|
|
91
|
-
Plain view:
|
|
92
|
-
|
|
93
|
-
```text
|
|
94
|
-
user input
|
|
95
|
-
-> CLI / interactive prompt loop
|
|
96
|
-
-> terminal-session prompt ownership + buffered replay boundary
|
|
97
|
-
-> BuilderAPI facade
|
|
98
|
-
-> BuilderApp turn kernel and provider adapter
|
|
99
|
-
-> registered tool contract and common entry boundary
|
|
100
|
-
-> policy-gated, resource-bounded execution
|
|
101
|
-
-> observation and artifact references
|
|
102
|
-
-> typed turn exit and optional verified mission outcome
|
|
103
|
-
```
|
|
104
|
-
|
|
105
|
-
Builder is a domain-neutral runtime with a security-focused distribution.
|
|
106
|
-
Development, pentesting, CTF, audit, and release behavior layers in through
|
|
107
|
-
context, tools, and skills rather than new core strategy kinds.
|
|
108
|
-
|
|
109
|
-
### Runtime persistence ports
|
|
110
|
-
|
|
111
|
-
Hot-path consumers depend on ten cohesive persistence ports:
|
|
112
|
-
|
|
113
|
-
```text
|
|
114
|
-
run/objective/evidence/task/execution/outcome
|
|
115
|
-
audit/observation/lineage/conversation-memory
|
|
116
|
-
|
|
|
117
|
-
local persistence composition root
|
|
118
|
-
```
|
|
119
|
-
|
|
120
|
-
Each producer/consumer depends on the smallest relevant port. The methodless
|
|
121
|
-
`ControlPlaneRepository` marker composes those ports only at construction and
|
|
122
|
-
dynamic storage boundaries. Implementations and test fakes implement the
|
|
123
|
-
physical ports directly; there are no blanket forwarding adapters, fallback
|
|
124
|
-
methods, alternate schemas, or second runtime state.
|
|
125
|
-
|
|
126
|
-
## 4. Engagement context and bounded CTF exploration
|
|
127
|
-
|
|
128
|
-
There is no model-backed intent classifier or weak/standard model mode in the
|
|
129
|
-
request hot path. Explicit event metadata is routed deterministically; absent
|
|
130
|
-
metadata receives one general strategy. Named profiles may add context, but
|
|
131
|
-
coarse labels do not authorize or reject tool calls.
|
|
132
|
-
|
|
133
|
-
CTF engagement metadata may select `ctf-competition` prompt context, and
|
|
134
|
-
`flag_check` remains a verification tool and evidence source rather than a
|
|
135
|
-
default completion gate. `explore` is always available; `[exploration]` only
|
|
136
|
-
sets node and fan-out caps. Installed users edit the relevant engagement, flag,
|
|
137
|
-
and frontier fields through `/config`.
|
|
138
|
-
|
|
139
|
-
The shipped exploration tool does not replace the core execution strategy.
|
|
140
|
-
It provides a bounded `EvidenceKind::Lead` ledger and explicit dispatch. Stable
|
|
141
|
-
generated identity is separate from semantic deduplication. Dead probes suppress
|
|
142
|
-
an execution branch without rejecting its knowledge hypothesis, and fresh
|
|
143
|
-
evidence reopens scheduling. An explicit `explore op=frontier` call reads one
|
|
144
|
-
canonical snapshot and returns a bounded attention brief: one visible focus, at
|
|
145
|
-
most two alternatives, at most two alerts, state counts, and an omitted count.
|
|
146
|
-
Focus is visibility, not a recommendation, authorization, or execution lock;
|
|
147
|
-
priority scores stay internal and the model must name leads in a separate
|
|
148
|
-
`dispatch` call. The model-facing payload stays within 4 KiB after JSON and HTML
|
|
149
|
-
escaping. On an explicit `/status`, the same pure projection is loaded once and
|
|
150
|
-
rendered as Battlefield Lite: at most eight logical rows and 1.5 KiB, containing
|
|
151
|
-
only typed counts/enums/numeric metadata and revalidated Lead IDs. It omits Lead
|
|
152
|
-
title, detail, parent/sample IDs, evidence references, tool output, and score;
|
|
153
|
-
that is a narrow Lead-prose disclosure boundary, not a general secret scanner
|
|
154
|
-
for the rest of the diagnostic output. There is no passive mission-control
|
|
155
|
-
injection, model-request hot-path repository read, `/frontier` command, detached
|
|
156
|
-
task registry, advisor, or second scheduler.
|
|
157
|
-
`orch_spec::exploration_e2e` pins the explicit frontier/pivot/dispatch/merge
|
|
158
|
-
behavior. A deterministic 256-Lead Phase 4 fixture measured the legacy rendered
|
|
159
|
-
frontier at 121,420 bytes and the bounded brief at 1,858 bytes (98.46% smaller),
|
|
160
|
-
while the existing completion-provenance corpus remained 9/9. This supports the
|
|
161
|
-
bounded visibility decision; it is not a claim of improved live-model solve rate.
|
|
162
|
-
|
|
163
|
-
Reliability guards sit below the profile layer. Provider protocol capabilities
|
|
164
|
-
default native tool support for OpenAI/Anthropic-compatible responses on
|
|
165
|
-
registry misses, unparsed tool-shaped markup becomes retryable instead of a
|
|
166
|
-
false completion, raw control markup is scrubbed from the stream, and the
|
|
167
|
-
markdown renderer flushes long no-newline prose at soft boundaries while still
|
|
168
|
-
bounding very large buffers.
|
|
169
|
-
|
|
170
|
-
```mermaid
|
|
171
|
-
flowchart LR
|
|
172
|
-
R[Request] --> GEN["Resolve<br/>task-shaped defaults"]
|
|
173
|
-
GEN --> REC["Optional<br/>named profile / pack"]
|
|
174
|
-
REC --> USE["Bound<br/>tool scope and budget"]
|
|
175
|
-
```
|
|
176
|
-
|
|
177
|
-
Request to closure:
|
|
178
|
-
|
|
179
|
-
```mermaid
|
|
180
|
-
flowchart TD
|
|
181
|
-
U[User request] --> A[Agent turn]
|
|
182
|
-
A --> M[Model output]
|
|
183
|
-
M --> T{Registered action?}
|
|
184
|
-
T -- no --> X[Typed turn exit]
|
|
185
|
-
T -- yes --> G[Common tool gateway]
|
|
186
|
-
G --> O[Observation]
|
|
187
|
-
O --> A
|
|
188
|
-
X --> V{Verified artifact?}
|
|
189
|
-
V -- no --> TC[TurnCompleted]
|
|
190
|
-
V -- yes --> MC[TaskComplete + provenance]
|
|
191
|
-
```
|
|
192
|
-
|
|
193
|
-
## Agent Team
|
|
194
|
-
|
|
195
|
-
The core agent team is domain-neutral. Each agent ships as a markdown persona
|
|
196
|
-
definition under `crates/builder_repo/src/agents/`.
|
|
197
|
-
|
|
198
|
-
Subagents are explicit and bounded. A `task` call selects one agent; its tasks
|
|
199
|
-
run concurrently up to four per call and delegation stops at depth two.
|
|
200
|
-
Separate top-level tool calls are sequenced. Built-ins include `crypto`, `rev`,
|
|
201
|
-
and `pwn`.
|
|
202
|
-
|
|
203
|
-
`explore dispatch` is a separate path. It runs selected leads as `builder`
|
|
204
|
-
clones with category overlays, defaults to breadth one, is hard-capped at four,
|
|
205
|
-
and waits for the batch. It does not auto-route leads to specialist personas.
|
|
206
|
-
Every child uses the same tool/policy gateway, budget, lineage, and evidence
|
|
207
|
-
merge contracts.
|
|
208
|
-
|
|
209
|
-
| Agent | Default role | Runtime profile |
|
|
210
|
-
| --- | --- | --- |
|
|
211
|
-
| `builder` | Hands-on implementation, refactoring, local file changes, tests | Implement + broad local write |
|
|
212
|
-
| `planner` | Implementation plans and risk breakdowns | Plan + read-only |
|
|
213
|
-
| `researcher` | Read-only codebase and reference research | Investigate + read-only |
|
|
214
|
-
| `coordinator` | Splits broad work into owned packets and consolidates results | Coordinate + broad local write |
|
|
215
|
-
| `investigator` | Evidence gathering across code, logs, commands, APIs, and behavior | Investigate + shell diagnostics |
|
|
216
|
-
| `operator` | Builds, tests, packaging, service startup, and runtime workflows | Implement + broad local write |
|
|
217
|
-
| `reviewer` | Findings-first technical review | Review + strict read-only |
|
|
218
|
-
| `verifier` | Reproduction, build/test proof, and completion claim checks | Verify + strict read-only |
|
|
219
|
-
| `report-writer` | Reports, handoffs, release notes, and reproducibility records | Implement + bounded write |
|
|
220
|
-
|
|
221
|
-
> Distinct tool-scope is runtime-enforced for `builder`, `planner`, and
|
|
222
|
-
> `researcher`; the remaining personas share a task-shaped generic profile
|
|
223
|
-
> (read-only when the task shape is review/verify, broad local write otherwise)
|
|
224
|
-
> and differ by their prompt instructions.
|
|
225
|
-
|
|
226
|
-
## Named Autonomy Profiles
|
|
227
|
-
|
|
228
|
-
Optionally pin the top-level profile (`autonomy_profile = "ctf-competition"`);
|
|
229
|
-
leave unset for the deterministic general default. CTF engagement config may
|
|
230
|
-
select CTF prompt context when no explicit profile is set, but it never changes
|
|
231
|
-
tool reachability. Delegated subagent contracts stay intact. Defined in
|
|
232
|
-
`crates/builder_domain/src/autonomy_profile.rs`.
|
|
233
|
-
|
|
234
|
-
| Profile | Purpose |
|
|
235
|
-
| --- | --- |
|
|
236
|
-
| `general-agent` | Broad autonomous local orchestration for mixed tasks |
|
|
237
|
-
| `local-builder` | Hands-on implementation with fresh evidence retrieval |
|
|
238
|
-
| `ctf-competition` | Competition/lab workflow; the profile references `ctf-competition` and `pentesting-methodology`, while built-in `write-report` remains explicitly selectable |
|
|
239
|
-
| `enterprise-review` | Strict, review-heavy profile with read-only dynamic scope |
|
|
240
|
-
|
|
241
|
-
## Engagement Metadata
|
|
242
|
-
|
|
243
|
-
Runs can attach typed engagement context — scope, phase, tags, flag format,
|
|
244
|
-
flag-evidence requirement, and standard refs (PTES, MITRE ATT&CK, OWASP,
|
|
245
|
-
CWE/CAPEC, NIST CSF, CIS Controls) — to workflow metadata. `/workflow report`
|
|
246
|
-
exports it as a Markdown handoff.
|
|
247
|
-
|
|
248
|
-
## Memory & Knowledge
|
|
249
|
-
|
|
250
|
-
Local-first and split across two complementary layers, no vector DB, no cloud:
|
|
251
|
-
|
|
252
|
-
- **Conversation memories** — facts/preferences/gotchas distilled from sessions,
|
|
253
|
-
persisted in local runtime state and recalled into each prompt by hybrid
|
|
254
|
-
retrieval. These carry a *strength* that fades like human memory, so the store
|
|
255
|
-
stays sharp instead of rotting.
|
|
256
|
-
- **Knowledge vault** — an optional Obsidian-style set of markdown notes under
|
|
257
|
-
`.pentesting/knowledge` (wiki-links, backlinks, tags). The agent reads it on every
|
|
258
|
-
turn and grows it with the `write` tool; it is never auto-deleted.
|
|
259
|
-
|
|
260
|
-
Both layers feed the same strength-weighted hybrid retrieval.
|
|
261
|
-
|
|
262
|
-
**Storage** — Ebbinghaus lifecycle (decay · reinforce · floor, never deleted):
|
|
263
|
-
|
|
264
|
-
```mermaid
|
|
265
|
-
flowchart TD
|
|
266
|
-
N[New memory] --> S["strength = quality × recall × e^-λ·age"]
|
|
267
|
-
S --> U{recalled?}
|
|
268
|
-
U -- yes --> RE[reinforce ↑ · reset age]
|
|
269
|
-
U -- no --> D[decay over time]
|
|
270
|
-
RE --> S
|
|
271
|
-
D --> F{below floor?}
|
|
272
|
-
F -- no --> S
|
|
273
|
-
F -- yes --> AR[de-reference: archive / tombstone]
|
|
274
|
-
AR -. recoverable on disk .-> N
|
|
275
|
-
```
|
|
276
|
-
|
|
277
|
-
Kinds fade at different speeds (procedural outlives episodic); bi-temporal
|
|
278
|
-
`event_time` vs `ingestion_time` lets newer facts supersede stale ones.
|
|
279
|
-
|
|
280
|
-
**Retrieval** — hybrid fuse, strength-weighted, read-only:
|
|
281
|
-
|
|
282
|
-
```mermaid
|
|
283
|
-
flowchart LR
|
|
284
|
-
Q[Query] --> L[Lexical]
|
|
285
|
-
Q --> SE[Semantic]
|
|
286
|
-
Q --> G[Graph]
|
|
287
|
-
L --> RRF[RRF fuse]
|
|
288
|
-
SE --> RRF
|
|
289
|
-
G --> RRF
|
|
290
|
-
RRF --> RR[rerank: phase · recency · task]
|
|
291
|
-
RR --> W[weight by strength]
|
|
292
|
-
W --> P[Prompt context]
|
|
293
|
-
```
|
|
294
|
-
|
|
295
|
-
Faded, private, or unsafe memories are held back from the prompt. Lookups never
|
|
296
|
-
write — reinforce/archive/supersede are explicit, never search side effects.
|
|
297
|
-
|
|
298
|
-
## Storage Strategy
|
|
299
|
-
|
|
300
|
-
Builder uses one operational storage strategy: local on-disk runtime state plus
|
|
301
|
-
markdown-native knowledge artifacts.
|
|
302
|
-
|
|
303
|
-
```mermaid
|
|
304
|
-
flowchart LR
|
|
305
|
-
W[Workspace files] --> AD[Source adapters]
|
|
306
|
-
S[Skills] --> AD
|
|
307
|
-
M[Conversation memories] --> AD
|
|
308
|
-
N[Markdown notes] --> AD
|
|
309
|
-
AD --> IDX[Local lexical + semantic + graph index]
|
|
310
|
-
IDX --> RR[Contextual reranker]
|
|
311
|
-
RR --> PC[Prompt context]
|
|
312
|
-
PC --> RUN[Agent run]
|
|
313
|
-
RUN --> LS[.pentesting local state]
|
|
314
|
-
RUN --> ART[Local artifacts and reports]
|
|
315
|
-
```
|
|
316
|
-
|
|
317
|
-
Key invariants:
|
|
318
|
-
|
|
319
|
-
- Runtime state is local-first and does not require an external data service.
|
|
320
|
-
- The markdown knowledge graph is derived from local facts: notes, skills,
|
|
321
|
-
conversation memory, wiki-links, backlinks, and run artifacts.
|
|
322
|
-
- Graph data is a derived retrieval view, not a second source of truth.
|
|
323
|
-
- Evidence, workflow runs, state cards, and verified artifacts persist through
|
|
324
|
-
local repositories. Removed semantic-verdict, recovery-route, completion
|
|
325
|
-
bundle, replay-archive, and curation projections cannot redirect the active
|
|
326
|
-
model loop because they no longer exist in the runtime model.
|
|
327
|
-
- Domain methods such as development, CTF practice, pentesting methodology,
|
|
328
|
-
audits, and release work live in skills and task instructions; they do not
|
|
329
|
-
change the core runtime identity.
|
|
330
|
-
|
|
331
|
-
## Crate Map
|
|
332
|
-
|
|
333
|
-
| Layer | Crates | Responsibility |
|
|
334
|
-
| --- | --- | --- |
|
|
335
|
-
| Interaction | `builder_main`, `builder_ratatui`, `builder_select`, `builder_markdown_stream` | CLI, TUI, prompt flow, rendering, selector fallback |
|
|
336
|
-
| Facade | `builder_api` | Thin application boundary used by entry points |
|
|
337
|
-
| Coordination | `builder_app` | turn loop, provider adaptation, common tool gateway, observations, verified outcome |
|
|
338
|
-
| Contracts | `builder_domain` | typed IDs, tools, workflow records, engagement metadata, policies |
|
|
339
|
-
| Capabilities | `builder_services` | tool services, auth, provider support, file/search/shell/fetch operations |
|
|
340
|
-
| Persistence | `builder_repo`, `builder_provider_repo` | local repositories, provider catalog, chat repository |
|
|
341
|
-
| Knowledge | `builder_knowledge`, `builder_workspace_index`, `builder_embed` | markdown note adapters, graph parsing, hybrid retrieval, local semantic scoring |
|
|
342
|
-
| Infrastructure | `builder_config`, `builder_infra`, `builder_fs`, `builder_walker` | config, environment, filesystem, process/runtime helpers |
|
|
343
|
-
| Support | `builder_display`, `builder_stream`, `builder_template`, `builder_json_repair`, `builder_snaps`, `builder_brand`, `builder_tracker`, `builder_test_kit`, `builder_tool_macros` | formatting, streaming, templates, JSON repair, snapshots, branding/theming, version tracking, tests, tool macros |
|
|
344
|
-
|
|
345
|
-
## Tool Surface
|
|
346
|
-
|
|
347
|
-
The runtime tool catalog is file, shell, network-fetch, planning, skill, todo,
|
|
348
|
-
and delegation oriented. Core tools:
|
|
349
|
-
|
|
350
|
-
- `read`, `write`, `patch`, `multi_patch`, `undo`, `remove`
|
|
351
|
-
- `fs_search`, `sem_search`
|
|
352
|
-
- `shell`, `fetch`
|
|
353
|
-
- `plan`, `skill`, `todo_read`, `todo_write`
|
|
354
|
-
- `task` and dynamically registered agent tools
|
|
355
|
-
|
|
356
|
-
The full catalog (`builder_domain/src/tools/catalog.rs`) also includes web
|
|
357
|
-
search, memory, verification primitives, session/process control, and
|
|
358
|
-
compaction tools. Security-session primitives, `flag_check`, and `explore` are
|
|
359
|
-
all present on the same surface. Engagement metadata supplies context;
|
|
360
|
-
permission and resource budgets constrain execution. Direct raw storage-query
|
|
361
|
-
tooling is not part of the active runtime surface.
|
|
362
|
-
|
|
363
|
-
## Verification And Completion
|
|
364
|
-
|
|
365
|
-
Turn closure and mission closure are separate:
|
|
366
|
-
|
|
367
|
-
```text
|
|
368
|
-
provider terminal
|
|
369
|
-
-> TurnExit
|
|
370
|
-
-> TurnCompleted
|
|
371
|
-
|
|
372
|
-
candidate outcome + trusted artifact
|
|
373
|
-
-> bind objective + target + verifier + artifact + freshness
|
|
374
|
-
-> MissionState::Verified
|
|
375
|
-
-> TaskComplete
|
|
376
|
-
```
|
|
377
|
-
|
|
378
|
-
The key rule is that a model response may finish a turn but cannot prove the
|
|
379
|
-
mission. The former completion-adjudicator, semantic self-review, consensus
|
|
380
|
-
panel, recovery synthesis, and hot-path replay export have been removed. A
|
|
381
|
-
trusted verifier with explicit provenance is the only mission-promotion path;
|
|
382
|
-
`flag_check` is the direct CTF fast path.
|
|
383
|
-
|
|
384
|
-
## Diagnostic UI boundary
|
|
385
|
-
|
|
386
|
-
The default TUI renders the response stream and deterministic input queue. It
|
|
387
|
-
does not maintain a second workflow engine. `/status` consumes one immutable
|
|
388
|
-
`RunStatusProjection`; `/workflow report` is the explicit offline export. The
|
|
389
|
-
former bare `/workflow` alias has been removed. For an active run the projection
|
|
390
|
-
adds exactly one optional canonical Lead-ledger read and immediately reduces it
|
|
391
|
-
to `Option<AttentionBrief>`; raw nodes never cross the API boundary, an optional
|
|
392
|
-
read failure only renders `BATTLEFIELD [UNAVAILABLE]`, and no Lead produces no
|
|
393
|
-
battlefield rows. Core status read failures retain their existing error path.
|
|
394
|
-
With no recorded run, `/status` still shows goal, manual/auto mode, queue, and
|
|
395
|
-
usage without an evidence read. Recorded `TurnExit` and typed `MissionState` are
|
|
396
|
-
shown separately so model Stop or run completion cannot appear as verified
|
|
397
|
-
mission completion. The live status row deliberately remains limited to
|
|
398
|
-
actionable progress/wait state: there is no frontier parsing, background refresh,
|
|
399
|
-
write, dispatch shortcut, or hidden chrome state.
|
|
400
|
-
|
|
401
|
-
Completed type-ahead inputs carry an explicit active-turn behavior. Safe
|
|
402
|
-
inspection commands (`/info`, `/usage`, `/context`, `/memory`, `/status`,
|
|
403
|
-
`/help`, `/skill`, and `/tools`) are atomically extracted and
|
|
404
|
-
rendered without cancelling the response stream. State-changing and modal
|
|
405
|
-
commands, including `/log` and `/model`, remain in FIFO order until the next safe turn
|
|
406
|
-
boundary. `/new`, `/retry`, `/exit`, and explicit `/replace` retain interrupt
|
|
407
|
-
semantics and take priority over active-turn query extraction. The input buffer
|
|
408
|
-
rebuilds replay events after extraction so queued messages and the current draft
|
|
409
|
-
preserve their original order and cursor. Esc cancellation preserves submitted
|
|
410
|
-
queued input and starts its FIFO replay after stream cleanup; Ctrl+C remains the
|
|
411
|
-
explicit clear-buffer interrupt. A conversation reset consumes `/new` but retains
|
|
412
|
-
its FIFO tail for the new conversation. Modal prompts isolate that pre-existing
|
|
413
|
-
tail from widget input and expose it again only after modal ownership ends.
|
|
414
|
-
Commands that eventually open a modal keep the outer interrupt listener during
|
|
415
|
-
their asynchronous prefetch and persistence phases. Before the widget starts,
|
|
416
|
-
the terminal session requests a reader pause and waits for its acknowledgement;
|
|
417
|
-
the reader resumes after modal ownership ends. Type-ahead is therefore buffered
|
|
418
|
-
FIFO instead of racing or leaking into a later model, agent, or configuration
|
|
419
|
-
field. Service-layer approval, secret, selection, and follow-up prompts acquire
|
|
420
|
-
the same lifetime-bound modal handoff through the prompt-entry hook, and
|
|
421
|
-
concurrent service prompts are serialized so two widgets never read stdin at
|
|
422
|
-
once.
|
|
423
|
-
|
|
424
|
-
`/resume` is the canonical saved-session selector; `/conversation` and
|
|
425
|
-
`/conversations` remain compatibility aliases. The selector includes every
|
|
426
|
-
conversation with persisted context, even when it has no title. Resuming a
|
|
427
|
-
different conversation clears the process-local goal and forces auto mode off,
|
|
428
|
-
so state from the previous session cannot drive the resumed one accidentally.
|
|
429
|
-
`/new` applies the same process-local goal/auto reset at the fresh-session
|
|
430
|
-
boundary while preserving the queued FIFO tail. Persisted titles are reduced to
|
|
431
|
-
one bounded control-free selector row before that row is bound to its typed
|
|
432
|
-
conversation ID. Local upserts stamp the activity time used by `/resume`,
|
|
433
|
-
`--continue`, and `conversation resume <id>` ordering. The command remains
|
|
434
|
-
FIFO-queued while a turn is active because its selector is a modal terminal
|
|
435
|
-
owner.
|
|
436
|
-
|
|
437
|
-
Normal `/exit` and empty-prompt Ctrl+D termination are serialized through the
|
|
438
|
-
output actor. It rejects new writes, completes its current render batch, resets
|
|
439
|
-
styles and terminal modes, restores the full scroll region, clears the tracked
|
|
440
|
-
multiline footer, shows the cursor, disables raw mode, and drops the terminal
|
|
441
|
-
surface before printing one plain saved-session message. The shutdown
|
|
442
|
-
acknowledgement and actor join occur after that message, so no detached redraw
|
|
443
|
-
can overwrite terminal cleanup. The generic `restore_terminal` function is a
|
|
444
|
-
best-effort fallback for failures outside this coordinated path. An empty
|
|
445
|
-
session reports that no resumable messages were created instead of promising a
|
|
446
|
-
session that the repository intentionally excludes from the resume list.
|
|
447
|
-
|
|
448
|
-
Typing `/` opens the complete registered command catalog. Search includes
|
|
449
|
-
canonical names and aliases; Up/Down changes the selection, and Enter inserts
|
|
450
|
-
the selected template into the editor for partial matches and commands that
|
|
451
|
-
require arguments. A later Enter submits that populated input; a fully typed
|
|
452
|
-
exact command that needs no expansion submits normally. Palette descriptions
|
|
453
|
-
expose `[now]`, `[queued]`, and `[interrupt]` so the queue behavior is visible
|
|
454
|
-
before submission. The selected entry is rendered as the first hint row so it
|
|
455
|
-
remains visible when the terminal can show only a constrained input viewport.
|
|
456
|
-
|
|
457
|
-
## Distribution — single source, two surfaces
|
|
458
|
-
|
|
459
|
-
Pentesting and Builder share the **same Rust runtime binary**. The `pentesting`
|
|
460
|
-
npm package is a thin distribution facade:
|
|
461
|
-
|
|
462
|
-
```text
|
|
463
|
-
npm install -g pentesting
|
|
464
|
-
│
|
|
465
|
-
▼
|
|
466
|
-
pentesting CLI (Node.js shim)
|
|
467
|
-
│ resolves or downloads the matching Builder release asset
|
|
468
|
-
▼
|
|
469
|
-
Builder binary (Rust) ← single runtime engine
|
|
470
|
-
│ PENTESTING_PRODUCT_NAME=pentesting
|
|
471
|
-
▼
|
|
472
|
-
Interactive TUI with "pentesting" banner
|
|
473
|
-
```
|
|
474
|
-
|
|
475
|
-
- The npm package installs a launcher, **not** a second agent runtime.
|
|
476
|
-
- It resolves or downloads the correct release asset from
|
|
477
|
-
`agnusdei1207/pentesting-public`.
|
|
478
|
-
- It forwards arguments directly into the Rust binary — no command translation
|
|
479
|
-
or compatibility shims.
|
|
480
|
-
- If a change would add orchestration, memory, or prompt logic into the npm
|
|
481
|
-
layer, that change belongs upstream in the Rust runtime.
|
|
482
|
-
|
|
483
|
-
## Supported Runtime Targets
|
|
484
|
-
|
|
485
|
-
The npm launcher currently resolves a managed native release asset for Linux
|
|
486
|
-
x64. Docker is the recommended runtime on Windows and macOS. Published Docker
|
|
487
|
-
images support `linux/amd64` only; Apple Silicon Macs use Docker Desktop's amd64
|
|
488
|
-
emulation. Native ARM64 images and binaries are not supported. Advanced users
|
|
489
|
-
may set `PENTESTING_BIN` to a locally supplied compatible binary.
|
|
490
|
-
|
|
491
|
-
| OS | CPU | Release asset |
|
|
492
|
-
| --- | --- | --- |
|
|
493
|
-
| Linux | x64 | `pentesting-x86_64-unknown-linux-musl` |
|
|
494
|
-
|
|
495
|
-
`/update` (and the npm postinstall) resolves the matching asset for the current
|
|
496
|
-
supported OS/CPU target from `agnusdei1207/pentesting-public`.
|
|
497
|
-
|
|
498
|
-
## Build containment boundary
|
|
499
|
-
|
|
500
|
-
Compilation is outside the application runtime boundary and is always executed
|
|
501
|
-
through resource-capped Docker wrappers. Host Cargo is not an emergency
|
|
502
|
-
fallback. `dbuild.sh` owns individual Cargo commands, `dverify.sh` owns
|
|
503
|
-
sequential gate profiles, and `dbuild-image.sh` owns BuildKit. Each path shares
|
|
504
|
-
storage admission, effective-limit inspection, a machine-wide lock, watchdogs,
|
|
505
|
-
and structured failure reports. Automated CI/CD is disabled; maintainers invoke
|
|
506
|
-
these wrappers explicitly. The
|
|
507
|
-
normative contract is [Docker-only build safety](https://github.com/agnusdei1207/pentesting/blob/main/docs/BUILD_SAFETY.md).
|
|
508
|
-
|
|
509
|
-
Patch publication performs one Cross build. The version-checked, checksummed
|
|
510
|
-
AMD64 musl artifact is uploaded to GitHub and packaged into Docker from a
|
|
511
|
-
minimal context; its dependency cache stays in a versioned Docker volume.
|
|
512
|
-
|
|
513
|
-
The measured next-stage simplification and deletion plan is indexed at
|
|
514
|
-
[Minimal Core plan](https://github.com/agnusdei1207/pentesting/blob/main/docs/plans/2026/07/10/minimal-core/README.md).
|
|
515
|
-
The concrete PTY actor, unified security-tool surface, turn-trajectory, and dead-path reduction is
|
|
516
|
-
recorded in [the 2026-07-10 implementation report](docs/plans/2026/07/10/IMPLEMENTATION_LightweightCoreRefactor_2026-07-10.md).
|
|
517
|
-
|
|
518
|
-
## Configuration
|
|
519
|
-
|
|
520
|
-
Pentesting reads a user-global config from `~/.pentesting/.pentesting.toml`,
|
|
521
|
-
overridden by project-local `.pentesting.toml` files discovered by walking up
|
|
522
|
-
from the working directory. Local storage is the default; normal setup only
|
|
523
|
-
needs the public model endpoint environment.
|
|
524
|
-
|
|
525
|
-
The full file shape is represented in `builder.schema.json`; common runtime and
|
|
526
|
-
CTF fields are editable through `/config`. Set `PENTESTING_CONFIG` to override
|
|
527
|
-
the global config directory.
|
|
528
|
-
|
|
529
|
-
| Variable | Description |
|
|
530
|
-
| --- | --- |
|
|
531
|
-
| `OPENAI_API_KEY` | API key or gateway token for OpenAI-compatible providers. |
|
|
532
|
-
| `OPENAI_BASE_URL` | OpenAI-compatible base URL, for example `https://api.openai.com/v1` or a self-hosted gateway. |
|
|
533
|
-
| `OPENAI_MODEL` | Default model id. |
|
|
534
|
-
| `OPENAI_MAX_TOKENS` | Optional output-token override; accepts values like `4096`, `32k`, or `1M`. |
|
|
535
|
-
| `PENTESTING_BIN` | Use an already-installed Builder binary instead of the managed download. |
|
|
536
|
-
| `PENTESTING_PRODUCT_NAME` | Runtime banner label. The `pentesting` launcher sets this to `pentesting` automatically. |
|
|
537
|
-
| `PENTESTING_REPO` | Override the public release repo used for binary downloads. Defaults to `agnusdei1207/pentesting-public`. |
|
|
538
|
-
| `PENTESTING_SKIP_DOWNLOAD` | Skip the postinstall binary download. Useful in CI or when `PENTESTING_BIN` will be provided later. |
|
|
539
|
-
| `PENTESTING_CONFIG` | Override the global config directory. |
|
|
540
|
-
|
|
541
|
-
### Canonical configuration contract
|
|
542
|
-
|
|
543
|
-
The next-generation runtime accepts one product namespace. Configuration uses
|
|
544
|
-
`PENTESTING_*`, `~/.pentesting/.pentesting.toml`, and project-local
|
|
545
|
-
`.pentesting.toml`. `BUILDER_*`, `.builder.toml`, `.builder/`, JSON config
|
|
546
|
-
fallbacks, and runtime alias translation have been removed. Existing users must
|
|
547
|
-
move data explicitly before upgrading; the runtime does not carry a permanent
|
|
548
|
-
old/new branch.
|
|
549
|
-
|
|
550
|
-
## Interactive Commands
|
|
551
|
-
|
|
552
|
-
Inside an interactive session, these commands inspect and drive runtime state
|
|
553
|
-
(`/help` lists the full set):
|
|
554
|
-
|
|
555
|
-
```text
|
|
556
|
-
/status Show goal/mode/queue, turn vs mission, run gates, budgets, and a bounded read-only battlefield
|
|
557
|
-
/workflow report
|
|
558
|
-
Export the active run, engagement metadata, evidence, and large outputs to Markdown
|
|
559
|
-
/context Show recent context-budget snapshots for the current conversation
|
|
560
|
-
/memory Show stored conversation memories for the current conversation
|
|
561
|
-
/tools List the currently available tools and schemas
|
|
562
|
-
/agent Switch the active agent
|
|
563
|
-
/resume Resume a saved session for the active workspace
|
|
564
|
-
/goal <task> Set the active goal without enabling autonomous mode
|
|
565
|
-
/auto Toggle autonomous mode for the current goal (default: off; Esc stops it)
|
|
566
|
-
/update Download and apply the latest public release asset for supported native targets
|
|
567
|
-
/help Show all commands
|
|
568
|
-
/exit Save the session, restore the terminal, and quit
|
|
569
|
-
```
|
|
570
|
-
|
|
571
|
-
## Security Domain Skills
|
|
572
|
-
|
|
573
|
-
Six built-in skills ship with the runtime: `create-skill`, `execute-plan`,
|
|
574
|
-
`github-pr-description`, `ctf-competition`, `pentesting-methodology`, and
|
|
575
|
-
`write-report`. For authorized security work, `ctf-competition` covers callback
|
|
576
|
-
delivery agility, reliable payload/tool delivery, and interpreter-aware
|
|
577
|
-
execution; `pentesting-methodology` maps assessments to standard frameworks;
|
|
578
|
-
and `write-report` turns preserved evidence into reproducible CTF and
|
|
579
|
-
penetration-test writeups.
|
|
580
|
-
|
|
581
|
-
- **PTES** (Penetration Testing Execution Standard)
|
|
582
|
-
- **MITRE ATT&CK** tactics and techniques
|
|
583
|
-
- **OWASP** Top 10 and Testing Guide
|
|
584
|
-
- **CWE/CAPEC** weakness and attack pattern catalogs
|
|
585
|
-
- **NIST CSF** and **CIS Controls**
|
|
586
|
-
|
|
587
|
-
### Shell listener for authorized labs
|
|
588
|
-
|
|
589
|
-
```bash
|
|
590
|
-
pentesting shell-listener --bind 127.0.0.1 --port 4444 --extra-ports 8443,9001
|
|
591
|
-
```
|
|
592
|
-
|
|
593
|
-
Up to 32 unique primary/additional ports bind concurrently and share one monotonic
|
|
594
|
-
session-id sequence; an unavailable port is skipped as long as at least one
|
|
595
|
-
requested port binds. `shell-session --json health` reports the active bound
|
|
596
|
-
endpoints so callback selection can be evidence-based. The remote-bind safety
|
|
597
|
-
gate remains unchanged.
|
|
598
|
-
|
|
599
|
-
Manages multiple accepted TCP sessions with per-session routing, buffered
|
|
600
|
-
output, raw byte logging, full-duplex transcripts, command history, attach /
|
|
601
|
-
detach events, replay, and evidence manifests. `probe` records the remote's
|
|
602
|
-
current shell interpreter in `shell`, detected only from `/proc/$$/exe` and
|
|
603
|
-
`$0`, so a BusyBox `sh` target is not confused with an installed Bash. This
|
|
604
|
-
interpreter axis is separate from TTY/`pty_state`; it is stored in session state,
|
|
605
|
-
the `shell-session --json` projection, session snapshots, and evidence manifests,
|
|
606
|
-
and is restored after a listener restart. `pty-upgrade` sends one concrete
|
|
607
|
-
helper only; `upgrade` runs a helper plus a probe and records `pty_state` as
|
|
608
|
-
verified or failed. Explicit `technique=auto` adds a bounded listener-side state
|
|
609
|
-
machine: framed capability recon, allowlisted `bash`/`sh` selection, ordered
|
|
610
|
-
helper attempts (`python3`, `python`, `python2`, `script`, `expect`), generic
|
|
611
|
-
prompt observation, and phase-local probe verification. Only unavailable,
|
|
612
|
-
early-returned, or completed-but-unverified attempts advance to the next
|
|
613
|
-
candidate; timeout, disconnect, or writer failure stops without blind input.
|
|
614
|
-
The entire operation keeps one command id, deadline, session lease, ledger, and
|
|
615
|
-
final response. There is still no silent default: omission is rejected, manual
|
|
616
|
-
techniques keep their single-attempt behavior, and custom text remains the
|
|
617
|
-
escape hatch for unusual targets. Raw logs and transcripts are capped per session and closed sessions
|
|
618
|
-
are archived automatically so a noisy peer cannot grow memory or disk without
|
|
619
|
-
bound. Secret redaction is applied before new raw/transcript/display records are
|
|
620
|
-
written; it is not retroactive for output that arrived before the secret value
|
|
621
|
-
was registered. Bound to loopback by default; `--allow-remote` is an explicit
|
|
622
|
-
opt-in gate.
|