MICROFORGE

CircuitPython / MicroPython Development Workbench

DEVELOP → INTEGRATE → VERIFY → RELEASE → PRODUCE → SUSTAIN

MICROFORGE 3.3 organizes the complete embedded-Python lifecycle around six engineering phases. The detailed 2.x benches remain intact, but Lifecycle now tells you what is current, what is blocked, what evidence exists, and what action should come next.

Current FocusDEVELOPProject and source are the current engineering basis.

Next Best ActionOpen EditorContinue development.

BlockingNONENo known lifecycle blocker.

Evidence ChainLOCALNo checkpoint-linked release chain yet.

Lifecycle assessment uses current local evidence.

Device

No device connected

Web Serial is requested only when you click Connect.

Runtime

Unknown

CircuitPython / MicroPython

Project

BlinkDemo

Local workspace

Status

Ready

Local changes are autosaved.

Browser Capability

Web Serial: checking…

File System Access: checking…

WebUSB: checking…

Quick Start

1. Open or create a project
2. Connect a board when needed
3. Edit + Run / REPL
4. Diagnose and Verify
5. Select deployment configuration
6. Deploy and Provision

Privacy

No account. No telemetry. No source upload. Device communication is local.

Last Event

Application started

—

Detailed Engineering Flow

LOCAL READY

1 · Project

Ready

Local source available.

2 · Configure

Optional

No deployment profile selected.

3 · Device

Not connected

Connect only when hardware work is needed.

4 · Sync

Local only

No hardware comparison yet.

5 · Runtime

Idle

Run or use the REPL on a connected interpreter.

6 · Evidence

Clear

No blocking diagnostics.

7 · Verify

Unverified

No checkpoint-linked verification evidence.

8 · Deploy

Not deployed

Use Deployment Bench after verification is READY.

9 · Provenance

No passport

Capture artifact ancestry after verification/deployment.

10 · Provision

No unit

Register and commission a physical unit after deployment.

11 · Batch

No batch

Create a production run from registered units.

MICROFORGE distinguishes local readiness from physical-device acceptance.

Hardware Characterization Bench

v3.3

Characterization describes observed behavior; it does not create PASS/FAIL acceptance by itself. Runs use current-window device measurements and retain their physical/Demo/session provenance. Statistical summaries are descriptive and do not imply calibrated uncertainty or causation.

Selected PlanNone

Metrics0

Runs0

SourceNO DATA

Current Measurement Window

Plan

Metric	Unit	Count	Mean	P95	Min	Max	Rate

Run Context

Characterization Runs

Before / After Comparison

Baseline run

Hardware Identity & Fingerprint

v3.2

Expected identity is project engineering intent. Observed identity is captured from the connected runtime/USB/filesystem where technically available. UNKNOWN means MICROFORGE did not obtain that evidence; it is not treated as a match.

AssessmentUNKNOWN

Device UIDUnknown

BoardUnknown

RuntimeUnknown

Expected ↔ Observed

Attribute	Expected	Observed	Result

Observed Hardware Fingerprint

Expected Hardware Contract

Fingerprint History

Engineering Dashboard

v3.1

A synthesized project-health view. Dashboard findings are derived from retained MICROFORGE evidence; they do not create new PASS/FAIL evidence or override the source workspace that owns each condition.

Engineering FocusDEVELOPAssessing project…

Attention Required0No active findings

Verification—No assessment

Fleet / Service0 / 0commissioned / active service

Attention Required

CLEAR

Engineering Health

Recent Engineering Activity

Trend Snapshot

Project Manager

ACTIVE PROJECT

MICROFORGE keeps one active project plus an inactive local Project Vault. Switching, creating, duplicating, forking, or importing first preserves the current project in the vault. Project source stays in browser storage unless you explicitly export it.

Project

ACTIVE

No description.

Project ID—

Project Version—

Runtime / Board—

Entry / Run—

Files0

Checkpoints0

Updated—

Stored Size—

Tags: None

Checkpoints

0Full local project snapshots · bounded to 20

Name	Created	Files	Hash	Actions
No checkpoints.

Project Vault

0 inactiveLocal browser storage · maximum 12 inactive projects

Project	Runtime	Status	Updated	Actions
No inactive projects.

Project Settings

Interpreter: —
Target board: —
Entry file: —
Run behavior: —
Preferred serial: —
Sync ignores: —

Templates

Starting a template archives the current active project before creating the new one.

Package Integrity

v1.5 project packages contain a canonical project hash plus per-asset integrity digests. SHA-256 is used when Web Crypto is available; any fallback is explicitly labeled in the package. Import verifies using the recorded algorithm before replacing the active project. Older v1/v2 project JSON remains importable but is labeled legacy/unverified.

Device Configuration Profiles

NO PROFILE

Configuration profiles are non-secret, project-controlled release inputs kept separate from source code and unit provisioning. Use Provisioning for passwords, tokens, credentials, private keys, or any value that should not persist in project packages and checkpoints.

Profiles0Development / bench / production / field

Schema Fields0Typed non-secret values

SelectedNONEChoose a profile to edit

DeploymentNONENo configuration overlay selected

Profiles

Configuration changes alter the verification baseline.

Profile	Environment	Validation	Updated	Actions
No configuration profiles.

Profile Values

0 fields

Field	Type	Value	Required	Actions
Define schema fields and select a profile.

Artifact & Deployment

Device path

Format

Deployment profile

Require a valid configuration profile during Deployment Allow configuration artifact to overwrite a verified-project path

Configuration artifacts are persistent non-secret release inputs. Do not place credentials or secrets here.

Selected Profile Preview

Select a profile.

Compare Profiles

Profile A

Profile B

Choose two profiles to compare effective values.

Test & Verification Bench

UNVERIFIEDFIXTURE OFF

Verification is tied to the current project content and, for deployment readiness, to a matching named project checkpoint. Automated tests only claim what MICROFORGE can observe directly. v2.1 can also consume structured evidence from a separately connected test fixture; a fixture PASS means the configured assertion matched the fixture's returned measurement, not that MICROFORGE independently measured the signal.

Test Cases0No reusable tests

Required0Required cases gate readiness

BaselineWorking stateNo matching checkpoint

DeploymentUNVERIFIEDNo current evidence

Reusable Test Cases

checkpoint before suite

Req.	Test	Type	Expectation	Latest	Actions
No verification cases.

Verification Runs

0Idle

When	Baseline	Result	Tests	Actions
No verification runs.

Deployment Readiness

Create a test suite and checkpoint-linked evidence to evaluate readiness.

Evidence Rules

PASS requires observed or explicitly operator-recorded evidence. BLOCKED means the test could not be executed. Demo Device results never satisfy physical-device connection/runtime/synchronization tests. Serial tests observe only data received after the test starts. A code or test-definition change makes older evidence stale because the project baseline digest changes.

Fixture Controller

Status: DISCONNECTED
Profile: None
USB: Unknown
Protocol: MF_FIXTURE/1 · line-delimited JSON
Last response: None

No fixture traffic.

The fixture is a second Web Serial device. MICROFORGE sends one request with a unique ID and accepts only the matching structured response. Fixture firmware defines the actual electrical stimulus/measurement behavior.

Supported Test Types

Device connected: Real DUT via Web Serial
Runtime match: Detected DUT runtime matches project expectation
Sync clean: Latest Project ↔ Device state is SYNCED
Static errors: No local ERROR diagnostics
Recent exception: No DUT exception inside the configured window
Serial contains: Wait for literal DUT RX text after test start
Serial regex: Wait for a JavaScript regular expression after test start
Fixture observation: Send a structured command to a second serial fixture and assert its response
Manual: Operator records PASS / FAIL / BLOCKED with notes

Advanced Evidence & Qualification

NO CAMPAIGN

Qualification campaigns organize retained Verification evidence into requirement coverage, repeated trials, revision/condition comparisons, deviations, and waivers. MICROFORGE only claims what the underlying Verification runs and operator records support; a waiver changes acceptance disposition, not the observed test result.

Requirements0

Campaigns0

Trials0

Coverage0%

DispositionUNQUALIFIED

Requirement / Test Matrix

Requirement	Criticality	Mapped Tests	Trial Evidence	Disposition	Actions
No qualification requirements.

Qualification Trials

0

When	Revision / Conditions	Verification	Pass Rate	Disposition	Actions
No trials captured.

Deviations & Waivers

ID	Type	Requirement	Rationale	Status	Actions
No deviations or waivers.

Campaign Definition

Name: —
Hardware revision: —
Firmware / project: —
Target trials: —
Created: —

Pass-rate Trends

Capture repeated trials to build trends.

Qualification Dossier Preview

No active campaign.

Deployment Bench

NOT READY

Deployment treats the checkpoint-linked verified project as authoritative. MICROFORGE writes project files to matching device paths and never deletes device-only files. Device-only extras are blocked by default because they can make the deployed runtime differ from the verified project. A deployment evidence digest is an integrity seal, not a digital signature.

Release Baseline—No checkpoint

VerificationUNVERIFIEDVerification must be READY

TargetNo devicePhysical hardware required

Latest DeploymentNONENo deployment evidence

Preflight Gates

Current local evidence

Evaluating deployment gates…

Device Write Plan

NOT COMPARED

Deployment writes the complete verified project and, when selected, the validated configuration profile artifact. Project paths are compared IDENTICAL after write; the configuration overlay is separately read back and hashed. Deletes: 0.

Path	Current Device State	Deployment Action
Refresh device evidence to build a current comparison.

Deployment Runs

0

When	Kind	Checkpoint	Write	Smoke	Result	Actions
No deployment runs.

Release Controls

Require every external imported library to be present in the project lib/, not only on the board. Block unmanaged device-only extra files. The selected configuration artifact and configured provisioning artifact are treated as sanctioned overlays; other extras still block by default. Require successful firmware-write evidence in this browser session.Operator / release owner Release note

Post-Deployment Smoke Tests

Choose enabled automated verification cases to execute immediately after the write and fresh Project ↔ Device comparison.

No automated verification cases available.

Evidence Model

Authority: Current matching project checkpoint
Write direction: Verified local project → device only
Deletion: Never performed by Deployment Bench
Post-write check: Fresh content comparison + selected smoke tests
Seal: SHA-256 when Web Crypto is available; fallback explicitly labeled
Signature: No cryptographic signing key is managed by MICROFORGE v1.9

Build & Artifact Provenance

NO PASSPORT

A Build Passport links evidence MICROFORGE already has; it does not invent missing ancestry. PROVEN means a concrete digest or matching record supports the link. UNPROVEN / MISSING / STALE remain visible. Passport integrity is tamper evidence, not a digital signature or identity proof.

Current ChainUNASSESSEDRefresh provenance evidence

CheckpointNONENo current verified checkpoint

Latest PassportNONENo captured build passport

Linked Units0No physical unit linkage

Current Ancestry Chain

Current local evidence

Refresh provenance evidence to build the chain.

Captured Build Passports

0

When	Label	Status	Checkpoint	Deployment	Units	Integrity	Actions
No build passports.

Artifact Identity

Project: —
Verification baseline: —
Environment lock: —
Firmware: —
Configuration: —
Deployment evidence: —

Physical Unit Linkage

No units linked to the current deployment.

Evidence Boundary

The passport records hashes, identities, and retained evidence relationships. A hash proves content identity only when the referenced bytes were actually observed. Firmware records that lack a retained artifact hash remain UNPROVEN. Operator labels remain attestations, not cryptographic identity.

Automation & Lab Mode

IDLE

Local orchestration, not unattended CI. Read-only/local steps may continue after you start a workflow. Any step that can stimulate hardware, run fixture/verification actions, deploy code, or write provisioning pauses at a one-step authorization boundary. Destructive controllers retain their own existing confirmation prompts as a second boundary.

Workflows0Project-local definitions

SelectedNONEChoose a workflow

Run StateIDLENo active run

AuthorizationNONENo gated step waiting

Run Evidence0Bounded local history

Workflow Definitions

Name	Steps	Risk Boundary	Last Run	Actions
No workflows.

Selected Workflow

Select a workflow.

Starter Workflows

Latest / Active Run

Run: —
Started: —
Finished: —
Result: —
Baseline: —

No run evidence.

Control Boundary

A workflow never grants blanket authorization. HARDWARE and DESTRUCTIVE steps pause before execution. Authorization applies to that one step only and is consumed immediately. Device connect/port selection remains browser-controlled and cannot be silently granted by a workflow.

Supported Step Types

Release & Provisioning Bench

NO UNIT

Provisioning is a unit-specific overlay applied after a verified deployment. Non-secret unit values may be stored with the project. Secret values exist only in the current browser session and are omitted from Project Vault copies, checkpoints, browser persistence, evidence exports, and fleet packages. MICROFORGE records whether a secret was supplied, never the secret itself.

Registered Units0Project-local unit registry

Selected UnitNONEChoose or create a unit

ReleaseUNDEPLOYEDCurrent verified deployment required by default

CommissioningINCOMPLETERequired checklist items gate completion

Unit Registry

0

Serial	Asset / HW Rev	Device Identity	Latest Release	Status	Actions
No registered units.

Provisioning Fields

Field definitions are project-level. Non-secret values are stored per unit. Secret values are session-only.

No provisioning fields defined.

Unit Release History

0

No unit release or provisioning events.

Selected Unit

Serial: —
Asset tag: —
Hardware revision: —
Lot / batch: —
Device UID: Not captured
Observed board: —
Observed runtime: —

Provisioning Artifact

Device path

Format

Require a current passing Deployment Bench run Require commissioning checklist completion before final COMMISSIONED status Allow provisioning to overwrite a path that belongs to the verified project

Secret handling

Secret field values are held only in memory for this page session. Switching projects clears them. They are not included in previews or exported evidence.

Redacted preview

Select a unit to preview provisioning metadata.

Commissioning Checklist

No checklist items.

Maintenance, Rework & Field Return

NO CASE

Service evidence is append-only lifecycle history. Opening, repairing, reprovisioning, retesting, or closing a service case never rewrites the unit's original production Deployment/Provisioning/Commissioning evidence. Operator-entered symptoms, causes, replacements, and dispositions are attestations unless backed by retained MICROFORGE device/test evidence.

Service Cases0Project-local lifecycle records

Open0Not closed/disposed

Rework / Retest0Active engineering action

Returned to Service0Closed with RTS disposition

Selected UnitNONESelect a case

Service Cases

Case	Unit	Type	Reported / Symptom	Status	Disposition	Actions
No service cases.

Service Timeline

0

Select a service case.

Selected Case

Case: —
Unit: —
Opened: —
Type: —
Status: —
Original release: —
Device UID: —

Select a case to inspect lifecycle evidence.

Evidence Boundary

A service event can reference current Deployment, Verification, Configuration, firmware, Build Passport, and connected-device observations. MICROFORGE records what was observed or linked; it does not infer a root cause from a repair action or treat a parts replacement as proof that a failure was corrected until retest evidence supports that claim.

Fleet & Batch Operations

NO BATCH

A batch organizes an operator-guided production run. MICROFORGE never loops over serial ports or performs unattended mass flashing/provisioning. Work Next Unit selects exactly one registered unit and opens the unit workflow; destructive actions still require the normal explicit physical-device confirmations.

Production Runs0Project-local operational records

Selected BatchNONEChoose or create a run

Progress0 / 0Commissioned units

Exceptions0HOLD / REWORK

Fleet0 commissionedAcross all registered units

Production Runs

Batch	Release	Units	Progress	Status	Actions
No production runs.

CSV import recognizes serial (required), assetTag, hardwareRev, lot, and notes. Columns matching non-secret provisioning keys are imported as unit values. Columns matching secret fields are deliberately ignored.

Exception / Rework Queue

0

No batch exceptions.

Sequential Unit Queue

0

#	Serial	Unit status	Queue	Release	Last evidence	Actions
Select a production run.

Release Matrix

Serial	Asset	Batch state	Deployment	Provision	Commission	Release version	Device UID
Select a production run.

BlinkDemoLOCAL

1

Project ↔ Device Synchronization

UNKNOWNNot compared

Compare is explicit. MICROFORGE uses a last-synchronized content baseline to distinguish local changes, device changes, and conflicts. Safe synchronization never deletes extra files on either side.

Idle

Identical

0

Local

0

Local-only / local changed

Device

0

Device-only / device changed

Conflicts

0

Ignored

0

Ignore Rules

Supports *, ?, and **. Leading / is optional.

Synchronization Policy

Safe plan: Local Only / Local Changes → upload; Device Only / Device Changes → download; Conflict → review. Force actions overwrite matching paths and copy missing paths, but still do not delete extras. boot.py remains protected by an explicit confirmation.

Binary project assets such as .mpy are stored locally as base64 project assets and can participate in synchronization. The editor opens text files only.

Path	Local	Device	State	Hash	Action
Connect a device and press Compare.

Device

DISCONNECTED

Hardware

Board: Unknown
MCU: Unknown
Architecture: Unknown
USB VID:PID: Unknown

Firmware

Interpreter: Unknown
Version: Unknown
Port: Web Serial
Board target: Unknown

Runtime

State: UNKNOWN
Free memory: Unknown
Frequency: Unknown
Filesystem: Unknown
Writable: Unknown

Serial Transport

Connection: DISCONNECTED
Baud rate

REPL mode: UNKNOWN
Interpreter override
Queue: Idle

Last transport error: None
Authorized reconnect: Idle

Raw REPL uses the standard Ctrl+A / Ctrl+B control convention where supported. Interrupt remains out-of-band so it can cancel a queued transfer or command.

Device Filesystem

0 entries

Idle · drop files or folders onto the filesystem table to upload

Path	Type	Size	Action
Connect a device and press Refresh.

Library Manager

RUNTIME UNKNOWN

Imports are resolved against firmware built-ins, project-local modules, local project lib/ assets, and the connected device's /lib inventory. MICROFORGE does not guess that a package is installed when the filesystem evidence is absent.

Required external

0

Unique project imports

Installed

0

Resolved on project/device

Missing

0

Actionable dependencies

Device /lib

0

Not inventoried

Compatibility

0

Items needing review

Project Dependencies

Import	Required by	Classification	Present	Compatibility	Action

Device Library Inventory

Connect a device and refresh /lib to inspect installed libraries.

Bundle / Compatibility Evidence

No local bundle manifest loaded. Raw .mpy headers can be reported, but full interpreter compatibility requires authoritative bundle/runtime metadata.

Install Policy

Selected files are written beneath /lib. Folder uploads preserve their relative paths. Existing paths are overwritten only after an explicit install action. Binary transfer uses the same byte-verified REPL transport as the Device workspace.

MicroPython package installation over mip is exposed only when the connected runtime confirms that module; otherwise install local files/folders.

Environment Lock

UNLOCKED

The environment lock records the target runtime/board plus exact hashes of project-carried lib/ assets. Device comparison hashes the connected board's matching files. A raw .mpy header is evidence only; compatibility is reported as UNVERIFIED unless authoritative bundle/runtime metadata supports a stronger conclusion.

Lock stateUNLOCKED

Runtime—

Board—

Locked files0

Last device compareNOT COMPARED

Module / path	Kind	Size	Digest	Compatibility evidence	Project / Device

Board Intelligence

PROFILE

Board Profile

Identification

Bootloader

Source Insertion

Pin rows insert a runtime-native expression when the selected profile defines one: board.X for CircuitPython or machine.Pin(...) for MicroPython.

Completion and board.X diagnostics use the same profile data shown here.

Pin Explorer

0 pins

Alias	Physical	MCU / Signal	Capabilities	Alternate Signals	Source

Extensions & Board Packs

LOCAL DATA ONLY

Declarative only. MICROFORGE extension packs are JSON data. Packs cannot execute JavaScript, inject HTML, override built-in board/API identities, or run arbitrary validation callbacks. Imported source provenance is recorded separately from content-integrity evidence.

Installed Packs0Local browser registry

Enabled0Applied to this browser

Board Profiles0Additional selectable targets

API Modules0Completion/reference additions

Installed Packs

Maximum 24 packs

Pack	Version	Trust	Contents	State	Actions
No extension packs installed.

Declarative Validation Findings

No enabled extension validation rules.

Selected Pack

Select a pack to inspect its declared contents and local integrity evidence.

Installed Knowledge

No extension knowledge applied.

Trust Boundary

A matching digest proves only that the imported JSON matches its declared content digest. It does not authenticate the author or publisher. Firmware source metadata remains informational; MICROFORGE does not automatically download third-party firmware from a pack.

Runtime Diagnostics

NO DEVICE

Static editor findings and device-reported failures are kept separate. Runtime diagnoses are evidence-based: MICROFORGE records the actual traceback/console signature it observed and labels heuristic classifications as such.

Observed Health

NO DEVICE

Connect a board to observe runtime behavior.

Last Exception

None

No device traceback captured.

Crash Loop

Not detected

3 matching failures / 30 s threshold.

Reset Reason

Unknown

Read from runtime when supported.

Memory Low-water

Unknown

Lowest observed gc.mem_free() snapshot.

Runtime Snapshot

Connection: DISCONNECTED
Runtime: Unknown
Free memory: Unknown
CPU frequency: Unknown
Filesystem: Unknown
Last snapshot: Never

Classification Rules

BOOT FAILURE: Traceback references boot.py.
STARTUP FAILURE: code.py/main.py traceback occurs shortly after an observed reset/reload.
MEMORY: Device reports MemoryError.
WATCHDOG: Console contains a watchdog/WDT reset signature.
HARD FAULT: Console contains HardFault, panic, or Guru Meditation signatures.
CRASH LOOP: Same failure is observed at least three times within 30 seconds.

Device Exceptions

0Click a source location to open the local project file when present.

Observed	Class	Exception	Location	Repeats	Evidence
No device exceptions captured.

Runtime Event Timeline

No runtime events captured.

Selected Evidence

Select an exception row to inspect its raw traceback and frame stack.

Debug & Measurement Bench

NO DEVICE

MICROFORGE measures only data it actually receives. Plain numeric telemetry can be watched, while structured runtime assertions, counters, events, units, and timing evidence use the explicit MFDBG/1 serial prefix. Performance baselines are engineering comparisons, not claims about signals the browser cannot observe.

Metrics0Numeric channels observed

Samples0Current session

Assertions0 / 0Pass / fail

Events0Structured timestamps

Baselines0Saved project comparisons

Watches & Runtime Assertions

0 WATCHES

Watch	Metric	Statistic	Current	Acceptance	Status	Actions
No watches defined.

Current Metric Statistics

Metric	Unit	Last	Min	Mean	P95	Rate	Samples
No numeric measurements captured.

Baseline Comparison

Capture or select a saved baseline to compare the current measurement window.

Saved Performance Baselines

No baselines saved.

Runtime Assertions

No structured assertions captured.

Event Timeline

No structured events captured.

MFDBG/1 Protocol

MFDBG/1 {"kind":"sample","name":"loop_ms","value":18.4,"unit":"ms"} MFDBG/1 {"kind":"counter","name":"frames","value":120} MFDBG/1 {"kind":"event","name":"sensor_ready","detail":"BME280 initialized"} MFDBG/1 {"kind":"assert","name":"buffer_ok","pass":true,"detail":"queue below limit"}

Only lines beginning exactly with MFDBG/1 are parsed as structured debug evidence. Ordinary application JSON is ignored.

Serial Instrumentation

NO DEVICE

The plotter observes real RX text from the connected serial stream. It accepts a line containing one numeric value, or complete numeric name=value pairs such as temperature=23.5,humidity=41.2. Console and REPL traffic continue normally.

Channels

0

Detected numeric signals

Samples

0

Bounded session capture

Last Sample

None

Waiting for numeric RX data

Window

30 s

Relative to latest sample

Live Serial Plotter

No telemetry samples captured.

Move the pointer over the plot to inspect the nearest samples.

Channels

No channels detected.

Accepted RX lines

23.5\ntemperature=23.5,humidity=41.2\nvoltage=3.29 current=0.081

Lines containing extra non-separator text are ignored so echoed REPL commands are not casually mistaken for measurements.

Firmware Catalog

SNAPSHOT

Catalog metadata is cached locally. Network refresh is explicit and reads the official CircuitPython or MicroPython download page for the selected target. MICROFORGE never auto-upgrades firmware.

Target

—

No target selected

Installed

Unknown

Connect a runtime for comparison

Latest Stable

—

From local catalog

Catalog

0

Not loaded

Runtime	Channel	Version	Date	Format	Flash	Comparison	Checksum evidence	Actions
Catalog not loaded.

Firmware Bench — UF2 / ESP

IDLE

SELECT BOARDSELECT FIRMWAREVALIDATEENTER BOOTLOADERFLASHVERIFYRECONNECT

Firmware Package

Target board

Firmware file

Detected typeNone

File size—

ValidationSelect a file

Idle

Hash: —
Runtime hint: Unknown
Version hint: Unknown
UF2 blocks: —
UF2 family: —
Address span: —

Bootloader Volume

NOT SELECTED

Volume: —
UF2 identity: Unknown
Model: Unknown
Board-ID: Unknown
Bootloader: Unknown

Advanced Overrides

Allow writing to a selected directory that does not expose INFO_UF2.TXT. This removes MICROFORGE's positive UF2-volume identity check. Allow a UF2 whose family IDs do not match the selected board profile. Use only when you have independently verified the target.

UF2 overrides apply only to the UF2 bench below. ESP erase/write controls are isolated in the ESP Firmware Bench and remain Advanced-only where destructive.

Recovery & Reconnect

Recovery starts with non-destructive bootloader access. MICROFORGE does not fetch, synthesize, or silently apply erase images.

Enter the board's UF2 bootloader using the board-specific procedure.
Select and inspect the boot volume.
Choose a known-good firmware image and validate it.
Flash only after the target evidence is acceptable.
Reconnect the runtime and verify the interpreter after re-enumeration.

No firmware reconnect attempted in this session.

Firmware History

No firmware operations recorded.

ESP Firmware Bench

ESP Binary Segments

IDLE

Select one or more binary images and enter the exact flash address supplied by the firmware publisher. MICROFORGE does not invent bootloader/partition/application offsets.

File	Address	Size	SHA-256
No ESP binary segments selected.

Add firmware segments and their documented addresses before programming.

0%

ESP Transport & Evidence

ENGINE NOT LOADED

Pinned Espressif esptool-js 0.6.0. Load is explicit.

Network loading fetches the pinned official browser bundle only when requested, records its SHA-256, and caches the text locally when browser storage permits. For fully offline use, select a trusted local esptool-js bundle.js.

ChipUnknown

USBUnknown

Baud—

Engine hash—

Advanced Flash Parameters

Baud

Mode

Frequency

Size

Erase the complete flash before writing the selected segments. This is destructive and receives an additional confirmation.

Erase is never automatic and never required merely to inspect or detect a chip.

Transport Log

ESP transport idle.

Recovery Bench

NOT ASSESSED

Recovery follows a non-destructive-first escalation model. MICROFORGE preserves evidence and offers reversible actions before destructive firmware or erase operations. It never formats a filesystem or erases flash automatically.

Observed Condition

Unknown

Run Assess to classify available evidence.

Recommended Level

0 · Observe

No recovery action selected.

Evidence

0 events

Diagnostics, filesystem and recovery actions remain local unless exported.

Safety

NON-DESTRUCTIVE

Escalation is explicit and reversible where possible.

0Observe & Preserve

READY

Capture current diagnostics and filesystem inventory before changing the board.

No recovery backup captured in this session.

1Runtime Rescue

REVERSIBLE

Interrupt execution, regain a friendly REPL, and attempt a soft reload before changing persistent files.

No runtime rescue action recorded.

2Startup File Rescue

REVERSIBLE FILE CHANGE

Temporarily move an auto-start file out of the interpreter's normal startup path. The original bytes are preserved under a timestamped .recovery-disabled-* name.

Disabling boot.py can change USB/filesystem behavior. MICROFORGE requires a second confirmation for boot.py and records the exact rename.

No startup file has been changed by Recovery Bench.

3Filesystem Triage

REVIEW BEFORE DELETE

Inspect free space and largest files. Deletion remains in the Device workspace so the exact selected path and confirmation are visible.

FilesystemUnknown

FreeUnknown

Known files0

Refresh/assess a connected board to rank device files.

4Firmware Recovery

FLASH CHANGES DEVICE

Use a known-good firmware image only after target evidence has been checked. RP2 boards route to the UF2 bench; ESP boards route to the ESP ROM-loader bench.

No firmware recovery operation initiated from Recovery Bench.

5Destructive Recovery

LAST RESORT

Whole-chip erase is exposed only for ESP devices through the existing ESP Firmware Bench. MICROFORGE does not implement automatic filesystem format, mass delete, or blind erase from this panel.

Back up recoverable files and export Recovery Evidence before destructive operations.