---

1.1 About this Volume

This is the first of a ten-volume engineer-grade reference on Bruce, the open-source ESP32 firmware published by pr3y and now maintained under the BruceDevices GitHub organisation. The series treats Bruce the way the rest of this hub treats the ESP32 Marauder firmware, the WiFi Pineapple and the Ducky Script family: as a platform to be understood at the level of its architecture, its hardware support, and its operating posture — not as a menu to be copied.

This volume establishes identity. It answers four questions that a reader has to settle before any of the technical detail means anything:

1. What is this thing? — a single, offensive-security multi-tool firmware for a wide range of ESP32 boards (§2).
2. Who stands behind it, and under what licence? — pr3y / BruceDevices, under the AGPL-3.0 for firmware and CERN-OHL-P-2.0 for the hardware (§3, §4).
3. Where did it come from? — it credits and reuses features from several earlier projects but is not a fork of any of them, and specifically not of ESP32 Marauder (§5).
4. When would someone reach for Bruce instead of a neighbour? — the comparison and decision graph (§6, §8).

The one structural rule for the whole series: because Bruce is a firmware, the load-bearing artefact is the “Where this firmware runs” table — the per-board support matrix. That table is the centrepiece of Vol 2; this volume only points down to it (§9). The hardware Bruce’s own team designed — the RF REAPER and the Smoochiee PCBs — gets Vol 3.

A deliberate boundary runs through the whole dive and is set here. Bruce is an offensive-security tool. Following the same rule used for the WiFi Pineapple and ESP32 Marauder dives, this series describes capabilities at the category level — what class of thing each subsystem does, plus the defensive and legal framing — and never reproduces the on-device menu tree or gives step-by-step offensive procedure. §10 states the envelope; the capability volumes (Vols 6–9) hold that line throughout.

Scope note. Everything here is written in an impersonal reference voice. No unit of this hardware is claimed as owned or bench-tested in this series; where a passage would naturally carry a first-hand build or field note, a marker is left for that to be added later rather than invented.

1.2 What Bruce is — the “predatory ESP32 firmware”

Bruce is a single firmware image that turns a supported ESP32 board into a handheld, menu-driven security multi-tool. The project’s own one-line description is blunt: “Bruce is a versatile ESP32 firmware packed with offensive-security tools, built to make Red Team operations fast and portable.” The repository’s long-standing tagline — the phrase the community uses — is “Predatory ESP32 Firmware.”

The defining characteristic is breadth. Where most ESP32 security firmwares specialise in one radio — Wi-Fi, or sub-GHz, or BLE — Bruce bundles essentially every radio and bus an ESP32 (and its optional add-on modules) can drive, behind one UI, on one SD card, with one configuration file. A single Bruce build can, depending on the board and the modules wired to it, work across:

 ┌───────────────────────────┐
 │ BRUCE │
 │ one firmware, one UI, │
 │ one bruce.conf on SD │
 └─────────────┬──────────────┘
 ┌──────────────┬──────────────┼──────────────┬──────────────┐
 ▼ ▼ ▼ ▼ ▼
 ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
 │ WiFi │ │ BLE │ │ Sub-GHz │ │ RFID/NFC │ │ IR │
 │ (deepest) │ │ │ │ (CC1101) │ │ (PN532…) │ │ │
 └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘
 ┌──────────────┬──────────────┼──────────────┬──────────────┐
 ▼ ▼ ▼ ▼ ▼
 ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
 │ NRF24 │ │ FM │ │ Scripts │ │ Connect │ │ Others │
 │ (2.4 GHz) │ │ radio │ │ (JS) │ │ (ESP-NOW…)│ │ BadUSB,QR │
 └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘

Each of those blocks is a top-level menu category on the device. None of them is unique to Bruce — there are dedicated firmwares that go deeper on any single one — but having all of them in one coherent build, across dozens of boards, is the thing Bruce does that nothing else does as widely. That is the whole value proposition, and it is why this dive spends a volume (Vol 2) purely on the board matrix: the firmware’s reach across hardware is its headline feature.

Two consequences of the breadth are worth stating up front, because they shape everything downstream:

• Not every feature exists on every board. A feature is only present if the board has (or is wired to) the hardware for it. A plain M5StickC has no CC1101, so it has no sub-GHz menu; an M5Stack Cardputer has a mic and a large feature set; a LILYGO T-Watch-S3 is effectively BadUSB-only. The firmware gates each feature at compile time against a per-board capability table — that mechanism is the subject of Vol 4, and the table itself is Vol 2.
• A full build does not fit every board. The richest boards carry a flash/PSRAM budget that smaller or Launcher-managed targets cannot meet, so Bruce ships a reduced LITE_VERSION on some boards that drops the heaviest features. The exact contents of that cut are detailed in Vol 5; it is flagged here because “which build” is as much a part of a board’s identity as “which chip.”

Bruce presents all of this through more than one control surface — the on-device screen and keypad, a browser-based WebUI served from the board’s own access point, a serial console, and a headless keyboard-shortcut mode. Those surfaces are architecture (Vol 4), but the point for identity is that Bruce is designed to be driven with or without its own screen, which is part of why it runs on screenless and tiny boards as readily as on a Cardputer.

The “micro-OS” framing. Because Bruce layers a launcher-compatible app, a configuration store, a file manager, a scripting interpreter and a hardware-abstraction layer over the Arduino-ESP32 core, it is often described as a micro-OS rather than a single tool. That is a fair mental model and it is reinforced by its relationship to the Launcher project (Vol 4): Bruce is built to be one app among several that a device launcher can load and update over the air.

1.3 Who makes it — pr3y, BruceDevices and the core team

Bruce originates with the GitHub user pr3y. Beyond the handle, biographical details — real name, nationality — are not confirmed by the project’s own materials, and this series does not assert any.The project is now hosted under the BruceDevices organisation: the canonical repository is github.com/BruceDevices/firmware, and the historic github.com/pr3y/Bruce URL redirects there. This matters for one practical reason that recurs through the dive:

pr3y/Bruce and BruceDevices/firmware are the same official project, reached by two URLs — not a mirror and not a fork. Several genuinely third-party re-uploads of Bruce binaries exist; those are mirrors and are not covered here. The official sites are the repository above, bruce.computer (project site), wiki.bruce.computer (documentation), bruce.computer/flasher (web flasher) and shop.bruce.computer (hardware shop).

Bruce is not a one-person project. The current architecture — the “new core” and the hardware-abstraction layer that make the wide board support possible — is credited substantially to @bmorcelli, who the README credits with “new core, many new features, and porting to many devices.” The broader credited team, taken from the repository’s own acknowledgements:

Table 1 — Bruce is not a one-person project. The current architecture — the "new core" and the hardware-abstraction layer that make the wide board support possible — is credited substantially to @bmorcelli, who the README credits with "new core, many new features, and porting to many devices." The broader credited team, taken from the repository's own acknowledgements

Contributor	Credited for
@bmorcelli	The “new core” / HAL, many features, and porting to many devices
@IncursioHack	RF and RFID module features
@rennancockles	RFID code, refactoring, and other features
@eadmaster	Many features
@7h30th3r0n3	Refactoring and Wi-Fi attack help (also author of Evil-M5Project)
@Tawank	Interpreter refactoring
@pablonymous	RF functions to read raw data
@Luidiblu	Logo and UI design
Smoochiee	Bruce PCB design (RF REAPER, PCB V2)
TH3_KR4K3N	M5StickC Plus extender PCB design

The project is backed by a public community: a Discord server running since 2026-07-22and, as a rough gauge of reach, on the order of 7.0k stars, 2.3k forks and ~3,250 commits on the main repository as of this writing.There is a first-party hardware shop (shop.bruce.computer) and PCBs sold through Elecrow; that commercial hardware side is Vol 3.

The current release is v1.16.1, labelled “Latest,” released on or about 11 August (the page does not print a year; 2025 is inferred).Its headline changes are a useful snapshot of where active work is going — note how much of it is Wi-Fi/BLE correctness and new-silicon stabilisation:

Table 2 — The current release is v1.16.1, labelled "Latest," released on or about 11 August (the page does not print a year; 2025 is inferred).Its headline changes are a useful snapshot of where active work is going — note how much of it is Wi-Fi/BLE correctness and new-silicon stabilisation

v1.16.1 change	Area
WPA3-PSK support; WPA2/WPA3 network detection	Wi-Fi
Brucegotchi handshake-capture fix	Wi-Fi (autonomous capture)
Station-Deauth fix	Wi-Fi
More Samsung OUIs added to BLE Spam	BLE
ESP32-C5 BLE crash fixes	New silicon (C5)
NetCut multi-target fix	Wi-Fi (MITM class)
CoreS3 SD-card conflict fix	M5 hardware
T-LoRa Pager encoder fix	LILYGO hardware

1.4 The licence — AGPL-3.0 and CERN-OHL-P

Bruce’s licensing is a two-part story, and getting it right matters because it is frequently mis-stated.

• The firmware is licensed under the GNU Affero General Public License v3 (AGPL-3.0). This is a strong copyleft licence. It is not MIT, and it is not accurate to call Bruce simply “open source” without naming the copyleft — the AGPL’s network clause means that distributing Bruce, or a derivative, carries source-availability obligations that a permissive licence would not. Several neighbouring projects in this hub (ESP32-DIV, SquachWatch, parts of Marauder) are MIT; Bruce is deliberately not, and a fork author inherits AGPL duties.
• The hardware designs — the PCBs — are licensed under CERN-OHL-P-2.0 (the CERN Open Hardware Licence, Permissive variant). This is what lets third parties (and the Elecrow shop) manufacture and sell Bruce’s board designs. The permissive OHL variant is the hardware analogue of a permissive software licence: manufacture and modification are allowed without a reciprocal share-back on the hardware side.
• Third-party code is tracked in THIRD_PARTY.md in the repository, which is where the copyleft-compliance and attribution details for borrowed components live. Because Bruce reuses code from several upstream projects (§5), this file is the authoritative map of what came from where.

 Bruce licensing at a glance
 ┌───────────────────────────────┬───────────────────────────────┐
 │ FIRMWARE (the.bin / source) │ HARDWARE (the PCB designs) │
 │ AGPL-3.0 (strong copyleft, │ CERN-OHL-P-2.0 (permissive │
 │ network clause) │ open hardware) │
 └───────────────────────────────┴───────────────────────────────┘
 borrowed code & attributions ──► THIRD_PARTY.md

The practical upshot for anyone building on Bruce: a firmware fork must stay AGPL and publish source; a PCB spin can be permissive. That asymmetry is intentional and is what makes the commercial hardware ecosystem (Elecrow-manufactured Smoochiee boards, Vol 3) possible without the firmware ceasing to be free.

1.5 What Bruce is not — it is not a Marauder fork

The single most common misconception about Bruce — reinforced by the fact that it runs on the same class of hardware and has a Wi-Fi attack menu — is that it is a fork of ESP32 Marauder. It is not. Bruce is an independent multi-tool firmware with its own core and its own project history. Where it uses ideas or code from earlier projects, it credits and borrows them; borrowing a feature is not the same as being a fork of its source tree.

The projects Bruce’s own documentation credits as sources of features or compatibility:

 Bruce's acknowledged lineage (feature-level reuse, NOT a fork of any):

 ESP32Marauder (justcallmekoko) ──► Wi-Fi/BLE attack features credited/reused
 M5Stick-Nemo (n0xa) ──► menu / tool ideas on M5 hardware
 Launcher (bmorcelli) ──► launcher compatibility (OTA app management)
 Evil-M5Project (7h30th3r0n3) ──► Evil-Portal-class / M5 tooling
 Doolittle (justinknight93)──► the JavaScript interpreter (Vol 9)
 │
 ▼
 ┌───────────────┐
 │ BRUCE │ own "new core" (bmorcelli), own HAL,
 │ (independent) │ own UI, own build system
 └───────────────┘

Two distinctions are worth making precise:

• Credited reuse vs. fork. Bruce reuses specific Wi-Fi/BLE attack code that traces to ESP32 Marauder, and it is launcher-compatible with bmorcelli’s Launcher. That is engineering reuse under the licences involved, documented in THIRD_PARTY.md. A fork, by contrast, is a continuation of another project’s whole source tree — and Bruce is not that of Marauder, Nemo, or any other single project. Its core was written for Bruce.
• “Ghost ESP / Bad Pinguino” framing comes from elsewhere. Those two names appear in this hub’s ESP32 Marauder dive as part of that project’s fork landscape; they are not in Bruce’s own documentation as ancestors or relatives of Bruce. They are brought into this dive only for the cross-firmware comparison in §6 and Vol 10, so that a reader standing in front of a pile of ESP32 boards can place Bruce against them — not because Bruce claims any relationship to them.

The reason to be careful here is not pedantry. Mis-labelling Bruce “a Marauder fork” leads to wrong expectations: that it is a Wi-Fi/BLE specialist, that its menus mirror Marauder’s, that a Marauder SD layout drops in. None of that holds. Bruce is a broad multi-tool with its own conventions; Marauder is a focused 802.11 Wi-Fi/BLE instrument. §6 makes the contrast concrete.

1.6 The firmware landscape — Bruce vs Marauder vs Ghost ESP vs Bad Pinguino

All four names below run on ESP32-class silicon and all are used for wireless security work, which is why they get conflated. They occupy genuinely different niches. The table is a positioning summary, not a benchmark — it is drawn from each project’s own stated scope and from the comparison in this hub’s ESP32 Marauder dive, not from head-to-head measurement.

Table 3 — 6. The firmware landscape — Bruce vs Marauder vs Ghost ESP vs Bad Pinguino

	Bruce	ESP32 Marauder	Ghost ESP	Bad Pinguino
Layer	Arduino-ESP32	Arduino-ESP32	ESP-IDF-native	Arduino (Marauder-family)
Scope	Broadest multi-tool: Wi-Fi + BLE + sub-GHz + RFID/NFC + IR + NRF24 + FM + scripting + connectivity	Focused 802.11 Wi-Fi + BLE L2 specialist	Lower-level, leaner Wi-Fi/BLE; research-grade capture & orchestration	Spanish-language Marauder-family fork
Added radios beyond Wi-Fi/BLE	CC1101 sub-GHz, NRF24, IR, FM, RFID/NFC	(add-on GPS; sub-GHz via external, limited)	mainly Wi-Fi/BLE	Wi-Fi/BLE
Board support	Very wide (M5Stack, LILYGO, CYD, Elecrow, own PCBs) — Vol 2	Wide, Marauder-centric reference boards	Several CYD/ESP32 boards	Marauder-class boards
Scripting	JavaScript interpreter (Doolittle lineage)	no	no	no
Control surfaces	On-device UI, WebUI, Serial, Headless	On-device UI, Serial	On-device UI, web, orchestration	On-device UI
Licence	AGPL-3.0 (HW: CERN-OHL-P)	MIT	open source	open source
In this hub	this dive	ESP32 Marauder Firmware dive	mentioned in Marauder dive	mentioned in Marauder dive

The one-line way to hold the four apart:

• Bruce — “everything, on the most boards.” Breadth and hardware reach are the point; depth on any single radio is traded for coverage across all of them plus scripting and connectivity.
• ESP32 Marauder — “the 802.11 and BLE L2 instrument.” Narrower and deeper on Wi-Fi/BLE; the reference for that work on this hub. (See the ESP32 Marauder Firmware deep dive.)
• Ghost ESP — “the ESP-IDF-native, lower-level one.” Leaner, research-grade capture and multi-device orchestration; less breadth of feature, closer to the metal. (Positioning here comes from a Ghost-ESP-leaning source, not a benchmark.)
• Bad Pinguino — a Spanish-language Marauder-family fork named in the hub’s Marauder dive; there is no reliable comparative data and it is out of scope beyond this mention.

The honest summary, and the one this dive carries into Vol 10: Bruce wins on breadth and on the number of boards it runs on; it does not claim to beat a focused specialist on that specialist’s home ground. If the job is deep 802.11 work, Marauder is the reference. If the job is “one device that can touch Wi-Fi, BLE, 433 MHz, NFC, IR and a bit of scripting, on hardware already on the bench,” that is Bruce’s case.

1.7 The capability map in one page

Below is the full set of Bruce’s top-level menu categories, named at the category level only. The capability volumes (Vols 6–9) expand each into what class of thing it does and the legal framing — never into a menu tree or offensive procedure. This map exists so the rest of the series has a shared vocabulary.

Table 4 — 7. The capability map in one page

Category	Class of function (category level)	Volume
WiFi	The deepest subsystem: connect/AP, recon & wardriving, deauth/disassoc, beacon/SSID spam, Evil Portal (captive-portal credential-harvest class), EAPOL/WPA handshake capture, raw sniffing, host/port scan, Responder, ARP spoof (MITM class), NetCut, Brucegotchi (autonomous handshake collector)	6
Connect	Connectivity stack — ESP-NOW file/command transfer; in the FULL build also Telnet, SSH, WireGuard, TCP client/listener	6
BLE	Scan/enumerate; Bad BLE (Ducky-style HID over BLE); BLE keyboard; advertising-spam flood classes (consent/region-sensitive)	7
NRF24	2.4 GHz jammer + spectrum view (Mousejack not yet implemented)	7
RF	Sub-GHz via CC1101 — capture/scan/copy, replay, custom payloads, spectrum view, jammers (TX illegal in most jurisdictions)	8
IR	TV-B-Gone, learn/replay across common consumer IR protocol families (low-risk)	8
FM	FM broadcast on FM-equipped boards (spectrum & TA-hijack not yet done)	8
RFID	HF read/clone/NDEF-write, 125 kHz LF read, Amiibolink + Chameleon support; PN532 / PN532Killer / ST25R3916 readers (tag emulation not yet implemented)	9
Scripts	A JavaScript interpreter (Doolittle lineage) with Core and Hardware modules; scripts run from SD	9
Others	Mic spectrum/FFT, QR (incl. PIX), SD + LittleFS file managers, WebUI, BadUSB (USB HID injection), USB keyboard, iButton, LED control	4, 9
Clock / Config	RTC/NTP/manual time; brightness, orientation, UI colour, boot sound, sleep, restart	4

Three items on this map are explicitly not finished in Bruce and are presented throughout as incomplete, not working: RFID tag emulation, NRF24 Mousejack, and FM spectrum / TA-hijack. Treating an unfinished feature as if it worked is a reliable way to misjudge the tool, so the series flags them wherever they come up.

1.8 Decision graph — which firmware for which board and goal

The following is a triage aid, not a ranking. It routes a reader from “what hardware and what goal do I have” to “is Bruce the right firmware, and if so which build.” It assumes the legal envelope in §10 is already satisfied.

 START: what is the job?
 │
 ┌─────────────────┼─────────────────────────────┐
 ▼ ▼ ▼
 "Deep 802.11 / "One device that "ESP-IDF-native, research-grade
 BLE L2 work, touches many capture / Wireshark streaming /
 nothing else" radios + buses" multi-device orchestration"
 │ │ │
 ▼ ▼ ▼
 ESP32 Marauder BRUCE ◄── this dive Ghost ESP
 (see that dive) │
 ▼
 Which board is in hand?
 │
 ┌───────┼───────────────┬───────────────────────┬────────────────┐
 ▼ ▼ ▼ ▼ ▼
 M5Stack LILYGO CYD (2432S028, Elecrow / Bruce's own
 Cardputer T-Embed 3248S035, NM-CYD-C5) bare ESP32-S3 PCB (RF REAPER,
 ADV / CC1101 / /C5 PCB V2) or none
 Stick S3 T-Deck … │ │ │
 │ │ ▼ │ ▼
 │ │ LITE build on some CYD/ │ richest hardware:
 │ │ Elecrow (Launcher size │ CC1101+NRF24+NFC+
 ▼ ▼ ceiling) — drops SSH/Telnet/ ▼ GPS+IR+Flipper hdr
 broadest mixed WireGuard/Brucegotchi/ full build (Vol 3)
 features (T-Watch, interpreter/… (Vol 5) where flash
 (full) Pager ≈ allows
 BadUSB-only)
 │
 ▼
 Need CC1101 sub-GHz, NRF24, NFC or a Flipper-style
 header but the board lacks it?
 │
 ┌────────┴────────┐
 ▼ ▼
 wire external or move to a Bruce PCB / RF REAPER
 modules (Vol 4 that integrates them (Vol 3)
 "External Modules")

The three questions that actually decide it:

1. Is the job broad or deep? Broad (several radios, one device) → Bruce. Deep on Wi-Fi/BLE only → Marauder. Low-level research capture → Ghost ESP.
2. What is already on the bench? Bruce’s strongest practical case is “flash it on hardware you already own.” Several boards in this hub already run it (§9).
3. Full or LITE? On Launcher-managed or flash-constrained boards, the LITE build is the only one that fits, and it is materially smaller in features (Vol 5). Knowing which build a board gets is part of choosing the board.

1.9 Where this firmware runs

Because Bruce is a firmware, the canonical answer to “what can I flash this on?” is a table, and that table is maintained as the centrepiece of the next volume.

See Vol 2 for the full supported-hardware table — every board and every build variant, with per-device capability columns (CC1101, NRF24, PN532/NFC, FM, Mic, BadUSB, RGB, Speaker, Fuel Gauge, PSRAM, LITE), the SoC of each, the build target, and where to obtain the board. Vol 3 then covers the hardware Bruce’s own team designed — the RF REAPER and the Smoochiee PCBs.

For orientation only, the shape of the supported range is: M5Stack (Cardputer and Cardputer ADV, M5StickC PLUS2 / PLUS, StickS3, M5Core BASIC, M5Core2, M5CoreS3/SE); LILYGO (T-Embed CC1101 and Plus, T-Embed, T-Display-S3, T-Deck / T-Deck Pro, T-Watch-S3, T-LoRa Pager); CYD boards (JCZN CYD-2432S028, CYD-3248S035, NM-CYD-C5 + RF HAT); Elecrow (2.4”B, Advance-3.5”-S3); bare/generic ESP32, ESP32-S3 and the newly supported ESP32-C5; and Bruce’s own PCBs (RF REAPER, PCB V2 / Smoochiee, Ultramarines, Pirata).

Three of those are tools this hub already documents and, in some cases, owns, which makes them the strongest “already-on-the-bench” entry points for Bruce:

• the M5Stack Cardputer ADV — full support, one of the broadest feature sets of any board;
• the M5Stick S3 — supported;
• any CYD-2432S028 — supported, but on the LITE build.

Those three names are carried verbatim into the Vol 2 table so the cross-reference links resolve; Vol 2 is where the per-feature detail for each lives.

1.10 How to read this series, and the legal envelope

The ten volumes. Vol 1 (this) identity and landscape; Vol 2 the supported-device matrix (the “where it runs” table); Vol 3 Bruce’s own hardware (RF REAPER and the PCBs); Vol 4 architecture and the HAL; Vol 5 build, flash and OTA, including the LITE build; Vols 6–9 the capabilities at category level — Wi-Fi & networking (6), BLE/NRF24/2.4 GHz (7), sub-GHz/IR/FM (8), RFID-NFC & the scripting interpreter (9); Vol 10 ecosystem, cross-firmware comparison and operating posture.

Cross-references are written in plain prose (“see Vol 2 §3”, “the ESP32 Marauder Firmware deep dive”) so the hub’s linker can resolve them.

The legal envelope — load-bearing, and it governs Vols 6–9. Bruce bundles capabilities that are lawful to own and study but unlawful to use against systems or spectrum one is not authorised to touch. The hub’s shared rules apply in full (see ../_shared/legal_ethics.md). In category terms, set here once so the later volumes can refer back:

Table 5 — The legal envelope — load-bearing, and it governs Vols 6–9. Bruce bundles capabilities that are lawful to own and study but unlawful to use against systems or spectrum one is not authorised to touch. The hub's shared rules apply in full (see [../shared/legalethics.md](../../shared/legalethics.md)). In category terms, set here once so the later volumes can refer back

Capability class	Envelope
Deauth / disassoc, Evil Portal, ARP spoof / NetCut (MITM), EAPOL/handshake capture	Authorised networks only — written permission or own equipment; these touch other people’s traffic
Sub-GHz jammers, NRF24 jammer, any continuous TX	Transmitting a jammer is illegal in most jurisdictions. Frame as bench / RF-shielded only; RF emission limits vary by region and band (433/315/868/915 MHz allocations differ by country)
BLE advertising spam	Nuisance / DoS class; consent- and region-sensitive
IR, passive scanning, FM receive, RFID read of own cards	Lower risk, but still own-equipment / authorised-target discipline

The series never tells a reader how to run a specific attack. It explains what each subsystem is, how it is built, what hardware it needs, and where the legal line sits — which is exactly the understanding needed to use the tool responsibly on authorised engagements and to defend against it. That boundary is set here and held through every later volume.

[FIGURE SLOT — Vol 1 §10] — a laminate-style one-card summary of the legal envelope table above, matched to the cheatsheet style used elsewhere in the hub.