Requirements and solving

A requirement is an object on the board: a region (a 2D constraint zone, a 3D volume, a net or the whole board), a quantity (a simulation overlay, a tool result, a DRC/ERC rule, a BOM field, geometry or routing), an aggregate, an operator and a limit (“max |E| ≤ 10 V/m at 2.45 GHz in this volume”, “max T ≤ 70 °C over the regulator”). Requirements are drawn as constraint zones (2D) or volumes (3D), evaluated continuously, listed with the other checks, and an agent or a built-in strategy can change the board until they are met (board ANA-3).

Constraint zones#

• Draw Constraint Zone (Zones flyout, or the palette; no default key): Tab cycles polygon, rectangle, circle, from footprint courtyard (click a footprint) and from net (click a track, pad or via: the net’s copper with a 0.5 mm margin). Closing the outline opens the requirement editor. The last shape, hole, draws a polygon inside an existing constraint zone and cuts it out of that zone (the smallest zone holding every corner takes it); the region is evaluated without its holes and the hatch leaves them empty.
• The requirement editor sets the name, the region (z range for volumes), the family, the quantity (picker grouped by source: the overlays loaded in the editor with their units and components, configured tools, DRC and ERC rules, BOM fields, geometry and routing keys), the aggregate, the operator, the limit and tolerance (SI prefixes and units accepted: 2.45 GHz, 70 °C), a time or frequency window, a spectrum/time mask, the severity, the weight, the evaluation mode and the tools it depends on. Save writes the requirement. A 2D zone lists its Holes (corners and size) with a remove button each; Add hole closes the editor and starts the zone tool in hole mode for that zone.
• The Requirements tab (right) lists every requirement with its status (satisfied green, violated red, unknown grey, stale amber), an enable toggle, edit, duplicate and delete. Clicking a row selects its zone.
• Appearance ▸ Layers ▸ Constraints lists the constraint layer families (EMI, Thermal, Mechanical, Current by default) with a hatch swatch, fill opacity, lock and visibility; clicking a family selects its zones and makes it the family of the next zones. The eye, lock and opacity of each family are kept per board in the workspace state, so they come back when the board is reopened. Board Setup ▸ Constraint Layers ▸ Families adds, renames, recolours and re-hatches families and assigns their layers.
• Storage stays KiCad-compatible: each 2D zone is a KiCad rule area that keeps nothing out, named req:<id>, on the family’s user layer (User.1…User.9, named “Constraints · ” when free), so KiCad shows and keeps it. Requirements, volumes and results live in <board>.kicad_requirements.json next to the board (referenced from the .kicad_pro as softforge.requirements). A zone moved in KiCad moves its requirement; a req: zone without a requirement becomes a disabled draft. Editing requirements is one undoable step with the zones. Changes that arrive together (a family table applied, a hole and its zone, a solve iteration) are batched: one undo step and one write of the JSON per batch, and one write again for each undo or redo. Holes live in the JSON only: the KiCad rule area keeps the outer outline.
• E or double-click on a constraint zone opens its requirement in the editor (a req: zone without a requirement keeps KiCad’s Rule Area Properties).

Constraint volumes (3D)#

• Draw Constraint Volume (Checks ▸ Requirements ▸ New constraint volume, or the palette) switches to the 3D view: box (click two corners on the board, move up or down for the height, click), sphere (centre, then the radius) or slab above a face (click a footprint for its courtyard, a zone, or empty board for the board outline, then the height); Tab cycles the shapes. Extrude the selected 2D zone turns a constraint zone into a volume with a z range. The requirement editor opens for the new volume.
• Volumes are drawn translucent in their family’s colour with the requirement’s label. A section cut (3D tab ▸ Cuts) outlines the volumes it crosses and shows the field slice inside them. Edit volume in 3D (a requirement row’s details) shows handles: drag the top or bottom face, Shift+drag to move the whole volume in z.

Evaluating requirements#

• Requirements are evaluated live: overlay requirements in the editor whenever an overlay or a frame arrives or the timeline moves; DRC, ERC, BOM, geometry and routing requirements in the extension after every edit, undo, KiCad save and checks run. A tool result older than the board is stale; a requirement whose source is missing (no simulation yet) is unknown.
• Checks ▸ Requirements groups them with the counts (satisfied / violated / unknown / stale), status filters, and per row the value, limit, margin and the worst location. Click a row to select the items, move the view (or the 3D camera) to the worst point and seek the timeline to the worst time; double-click opens the editor. Expanding a row shows the history sparkline (one point per solve iteration or recorded evaluation) and the hints. The group’s buttons evaluate now (running nothing), add a constraint volume and save the requirements report (Markdown or JSON).
• Markers sit at the worst points in 2D and 3D; violated requirements appear in the Problems view (on the line of their req: rule area) and Design health shows “Requirements: n satisfied / n violated / n unknown”.
• Component heights come from the footprints’ 3D models: the bounding box of the VRML (.wrl), STEP or glTF model, placed with the model’s offset, scale and rotation (the board top is z = 0), found through the model path’s variables (KICAD*_3DMODEL_DIR, the project’s text variables) and the .wrl/.step siblings. A footprint without a readable model uses its Height field, else a table of package heights (chip sizes, common IC and connector packages); the log names the models that could not be read.
• Mechanical quantities (interference, collision, enclosureClearance, envelope) come from the MCAD clearance run of the board against its enclosure (<board>.kicad_mcad.json) with the bodies at their model heights: the overlap depth, the number of colliding parts, the smallest clearance to the enclosure and how far the tallest part exceeds the height envelope. The 3D view’s own run (model meshes) is used when it reported one; add-ons can still set their own with setExternalQuantity.

Solving#

The solve loop changes the board until its requirements are met (board ANA-3). Each iteration: evaluate (running the tools the requirements depend on) → pick the violated requirements by weight → a strategy proposes edits → they are applied as one undo step with the DRC/ERC gate (an edit that adds a DRC or ERC error is rolled back and the iteration counts as failed) → the board is saved and the tools re-run → everything is re-evaluated. The score is Σ weight · max(0, −margin) over the violated requirements; an iteration that makes it worse is reverted (except annealing moves the strategy keeps on purpose).

• Electronics Designer: Solve Requirements… (softforge.edsnx.solve) opens the Solve dialog on the open board: tick the requirements (violated ones are ticked), pick a strategy (Auto takes the first that handles each requirement), set the budget (iterations, seconds, tool runs, the no-progress stop), the seed and the Gate (DRC/ERC check on every iteration), then Start. The iteration log shows each iteration (#, strategy, edits, violated, score, note; reverted and failed iterations struck through, the best one starred) with a sparkline of the score. Show diff draws the changed items of the selected iteration on the board (old boxes outlined, new ones filled). Visual diff opens review mode against the board at the start of the run: the review panel shows the before / after image with the changed pixels highlighted (overlay mode, with the start as the ghost layer, without Chromium). Accept keeps the result and records it in the requirement history; Revert returns to the start or to the best iteration; Replay opens the run’s log.
• Built-in strategies: Placement search (moves/rotates the footprint behind a temperature or field maximum away from the worst point: pattern search, then simulated annealing; candidates clear courtyards, keepouts and the board edge; the moved part’s tracks are ripped to ratsnest, or re-routed by the autorouter when reroute is set), Widen nets (current density: wider tracks, parallel bypasses), Stitch ground (emission: ground fill and stitching vias in the region), Swap for lower profile (height envelopes: pad-compatible lower footprints; parts are ranked by their 3D model height and a candidate’s height is its library model’s, so a candidate that is not lower is skipped), Autoroute (unrouted connections). Add-ons add theirs with api.solve.registerStrategy (see the add-on API).
• Agent (Claude via MCP): the loop writes a prompt with the results and hints and waits; Claude answers with solve_propose through the MCP server (claude mcp add edsnx -- edsnx mcp --attach), or a script writes .edsnx/solve-<id>.intents.json. The electronics-designer-solve skill teaches Claude the protocol.
• The loop stops when everything is satisfied, at the budget, after no progress iterations without a better score (the board returns to the best iteration), or on Cancel. The board is saved before tools run, since they read the file.
• From a shell: edsnx req eval board.kicad_pcb --run-tools --json, edsnx solve run board.kicad_pcb --strategy placementSearch --seed 1, edsnx solve status, edsnx --dry-run req add … (prints the change, writes nothing), edsnx solve replay, edsnx req report --out requirements.md (commands.md). Every run is logged to .edsnx/solve-<id>.jsonl next to the project: edsnx solve replay board.kicad_pcb --log .edsnx/solve-<id>.jsonl re-applies it on a board in the start state and checks every step’s hash and the final one.