Confirmations, records and agents

Actions that ask first

An engineer confirms every flash, erase and programming step, every memory write the module makes for you, and every change to a vendor project before it happens. Agents never write on their own: each agent tool that changes a target, a project or a setting asks you first. These actions show a confirmation, and do nothing until you accept it:

The confirmation before erasing one flash sector, naming the device, the probe, the sector range and the sector layout used.

Start Counting lists the debug-register writes it needs and writes nothing until confirmed.

Paint Stack asks first, naming the range below the stack pointer, the pattern and the image.

Values you change yourself in a halted debug session (a register or variable in the Variables view) are written when you enter them, as in any debugger. Start Cycle Stopwatch sets the DWT enable bits when you run it, and neuralInverse.embedded.debug.cycleStopwatch, once you turn it on, does so at the first halt of each session; an agent's call to start the stopwatch asks first.

The probe verification kits follow the same rule: they change a target only by flashing the reference image after you confirm at a prompt, and never write option bytes, protection or security settings.

Downloads

Nothing is downloaded unless you run a command that says so: Update Device Pack Index, Install Device Family Pack..., Select Device... and Download STM32 Pin Data. Each can point at a company mirror or an installed copy instead. See offline use.

What is recorded

These records are evidence toward the traceability your process requires (for example, which image was flashed to which unit). They are not a certification.

Your organisation's policy

With Neural Inverse Govern, a signed policy decides in-app actions in the Editor:

• Tasks and launch configurations. Builds run as tasks and debug sessions start from launch configurations; each task in a dependsOn chain is decided before any runs. A policy can allow, deny or require approval.
• Settings. neuralInverse.* settings, which the module writes (device, preset, probe, keymap), go through the same in-app check, and an organisation can govern the whole namespace.
• Hardware operations. The policy format has rules for domain-module operations such as flash, erase, fuse write and bitstream (domainActions: module, operation, targets, effect, approval rule). The Embedded module's flash, erase and programming operations are not submitted to that check, so the confirmations above are the control that stops an unintended write.

An action that needs approval asks you; in a session nobody attends, it is refused. When the policy names an approval rule, you cannot approve it yourself. See Govern.

Agent tools

An agent in the Editor can use these tools. Every tool that changes a project, a setting or the target shows the same kind of confirmation as above, and runs only when you accept it; read-only tools run without one.

State: the tools are covered by unit and Electron tests on Linux; their underlying actions have the states given on their pages.

In the CLI's firmware environment, flashing always needs a person's approval, in every permission mode including full-auto, even when an allow rule matches; non-interactive runs cannot flash. See CLI environments.