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 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, while submitted input resumes in FIFO order at safe turn boundaries |
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.7",
4
- "builderReleaseTag": "v0.101.7",
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.