pentesting 0.101.7 → 0.101.8

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/ARCHITECTURE.md CHANGED
@@ -2,7 +2,9 @@
2
2
 
3
3
  This document reflects the current `main` branch architecture. It is the single,
4
4
  detailed reference for how the runtime is structured; the [README](README.md)
5
- stays intentionally short and usage-focused.
5
+ stays intentionally short and usage-focused. For a diagram-level tour of the
6
+ main runtime flows, see [Main Flows](docs/architecture/MAIN_FLOWS.md). Both are
7
+ internal-only and are never mirrored to the public repo.
6
8
 
7
9
  > **Engine vs product.** The orchestration engine is **`builder`** — a
8
10
  > general-purpose, local-first Rust agent runtime. **`pentesting`** is the
@@ -394,11 +396,33 @@ battlefield rows. Core status read failures retain their existing error path.
394
396
  With no recorded run, `/status` still shows goal, manual/auto mode, queue, and
395
397
  usage without an evidence read. Recorded `TurnExit` and typed `MissionState` are
396
398
  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
399
+ mission completion. The live status row deliberately remains limited to
400
+ actionable progress/wait state: there is no frontier parsing, background refresh,
401
+ write, dispatch shortcut, or hidden chrome state.
402
+
403
+ Interactive `/auto` progress is producer-owned rather than inferred from the
404
+ latest conversation after the fact. Dispatch marks a self-prompt turn in flight;
405
+ successful cleanup captures that turn's final assistant markdown in memory,
406
+ records a deterministic completed-turn line in the transcript, and synchronizes
407
+ optional `current/target` progress to the footer before queued user input is
408
+ replayed. A regular `AUTO_GOAL_PROGRESS` line is observability-only.
409
+ `AUTO_GOAL_COMPLETE` retains completion authority and
410
+ `AUTO_GOAL_BLOCKED` remains non-terminal. Cancellation, goal/auto reset, and a
411
+ manual user turn invalidate pending completion provenance so a later reply
412
+ cannot be misattributed to the autonomous turn. Unexpected stream termination
413
+ also revokes ownership before queue replay, and explicit stop interrupts disable
414
+ auto mode before preserved input is replayed. Interrupt-listener shutdown
415
+ linearizes the terminal boundary as stop, reader join, then pending-source
416
+ recovery, so an Esc accepted concurrently with `TurnCompleted` wins before
417
+ progress or completion can be committed. Tool/delegated-agent markdown and
418
+ terminal events have no root completion authority while a nested producer owns
419
+ the stream. The auto footer is process-level chrome: turn-local backend resets
420
+ preserve it until an explicit UI state transition clears it. The footer receives
421
+ a bounded single-line goal projection, while the deterministic progress title
422
+ does not repeat the goal every turn, so multiline/control-bearing goals cannot
423
+ corrupt fixed chrome or inflate transcript history.
424
+
425
+ Completed type-ahead inputs carry an explicit active-turn behavior. Safe
402
426
  inspection commands (`/info`, `/usage`, `/context`, `/memory`, `/status`,
403
427
  `/help`, `/skill`, and `/tools`) are atomically extracted and
404
428
  rendered without cancelling the response stream. State-changing and modal
package/README.md CHANGED
@@ -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.8",
4
+ "builderReleaseTag": "v0.101.8",
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",