packpay - News

Version 0.72.77 (2026-10-11)
=============================
* In the picture, the jumpers that join a rail's strips are drawn as straight lines that start and end exactly on their rails. They were curves whose first end overshot the rail by a few pixels (the tie between two
  boards past the south rail of the first board, and every other bridge past its northern end). The instructions are unchanged.

Version 0.72.76 (2026-10-11)
=============================
* In the picture, the jumpers that join a rail's strips (a board's north and south rail, and one board's rail to the next) each have their own column instead of sharing one, so a chain of them no longer reads as one
  long wire; the end of one wire and the start of the next no longer land in the same rail hole. The instructions are unchanged.

Version 0.72.75 (2026-10-11)
=============================
* The build instructions now tell the builder to place the jumper wires that join a rail's separate strips: "Connect a jumper wire from the north ground (-) rail to the south ground (-) rail.", and the same for the power
  rail. The drawing always showed them; no step said so, so a builder following the text would have built two separate grounds on dudhya, rp2040, knight-roller and solar-roller. A board of several zones has a middle
  rail as well (north to middle, middle to south). On several boards the steps name the boards and tie one board's rail to the next ("... ground (-) rail of board 1 to the north ground (-) rail of board 2"), which a
  multi-board layout had never said: its boards would have had separate grounds. In the picture of several boards the ties between boards were almost invisible (two dashed stubs under the board); they are drawn now as the complete wires they are.

Version 0.72.74 (2026-10-11)
=============================
* ppkicad_layout and ppresolve_components now write KiCad 10 files by default, with a new option --kicad-version N to choose: 7 (written by the tool itself, no kicad-cli needed) or the version of the installed
  kicad-cli, to which the files are converted. A version that cannot be written is refused before anything is done, with what can be done instead. The circuit is the same in both formats, and a multi-sheet
  schematic opens in the KiCad 10 editor with its whole hierarchy and without the banner about an older file format. Behaviour change: kicad-cli is now needed to write with the default, not only to read a
  .kicad_sch input; --kicad-version 7 keeps the earlier behaviour. The environment variable PACKPAY_KICAD_VERSION sets the default.

Version 0.72.73 (2026-10-11)
=============================
* A schematic written over several sheets now opens in the KiCad 10 editor without the message "An error was found when loading the schematic that has been automatically fixed". The files were valid to
  kicad-cli, which every check uses, but KiCad 7 and later keep the page of each sheet inside the sheet symbol and the reference of each symbol under every sheet that uses its file, and the generator wrote
  neither (only the older list at the end of the root, and symbol data only for a file used more than once). Found by opening the output in the editor for the first time. A schematic on one sheet was never
  affected.

Version 0.72.71 (2026-10-11)
=============================
* The anchors (the chips and connectors that stand in a row) are placed in an order that keeps related parts closer to each other. Over the seven example designs the net jumpers of the build instructions are
  18% shorter in total (101 jumpers before and after), and on none of them longer; the schematic generator's sheets read better too (knight-roller's microcontroller now sits among its connectors). A layout
  that would leave a part unplaced is laid out again in the earlier order, since a missing part is worse than a long jumper. PACKPAY_ANCHOR_REFINE=0 restores the earlier order.

Version 0.72.69 (2026-10-11)
=============================
* A circuit with several supply voltages is no longer wired with all of them to the one power (+) rail of the breadboard, which joined them: rp2040's 1.1 V and 3.3 V supplies were both read "to the nearby
  power (+) rail", and its 5 V USB net was announced on that rail too. The supply with the most pins is the rail, and every other supply is wired like an ordinary net, with jumpers (rp2040 needs one more
  step for it). A circuit with one supply, and the six other example designs, are unchanged. A rail line per supply stays a possible redesign (see FutureResearch.org).

Version 0.72.68 (2026-10-11)
=============================
* The rail wire of a chip that is laid out as a diagram now says which of its pins it stands for: "Connect a jumper wire from hole j14 to the nearby ground (-) rail. U1's ground (-) pins 21, 3 go in this
  column: hole f14." Until now such a chip listed its pins on each rail without any hole, and where it had two supply voltages (rp2040: +1V1 and +3.3V) all of them were in one sentence, with two wires
  and nothing saying which pins went to which. Each wire is now checked against the circuit rebuilt from the instructions. Nothing else changes.

Version 0.72.67 (2026-10-11)
=============================
* Rebuilding a circuit from its instructions now reads the board the text says it is for ("Board: 15 rows per half.") also when the library call is used directly, not only through ppparse_instructions and
  ppresolve_components: on a taller board two holes of different halves used to be read as one strip and unrelated nets merged, silently. A hole that cannot exist on the default board, in a text that
  states no board, is now an error that names the hole instead of a wrong strip.

Version 0.72.66 (2026-10-11)
=============================
* The short jumper that connects a column to a rail is now a step. It was drawn (from the rail to the outermost row of the column) for a chip's rail column and for a passive's near and far lead, and no
  step told the builder to place it: a part said "also connects to the rails" or "(on the nearby ground (-) rail)" and left the wire to be inferred. Each is now a step right after its part: "Connect a
  jumper wire from hole j14 to the nearby ground (-) rail." The reader of the instructions checks each against the circuit it rebuilds.
* Three of the seven example designs had a real short, in every earlier version, which this check found. A far lead of one net was drawn in the same strip as another net's rail column: in knight-roller a
  resistor's ground lead shared a column with the chip's power wire, in solar-roller two columns did, in rp2040 ground shared one with USB_DP. The drawing hid it (one wire over the other) and the
  connectivity check could not see it. Both now know the rail columns; the layouts of those three designs change where needed and the others do not.

Version 0.72.65 (2026-10-11)
=============================
* The pin list of a part that stands where its footprint puts its pins (a header, a DIP) now holds every pin that is on a rail, each with its hole, as well as the pins on nets. A three-pin header with
  a signal, a ground and a power pin used to say "Its pins, from the left: 1 in a34." and leave a35 and a36 to be worked out; it now says "1 in a34, 2 in a35, 3 in a36". A part laid out as a diagram is
  unchanged.
* A real flaw of the physical layout of a DENSE chip circuit is closed. The strip of a chip's rail pin (its ground pin, a tied-high pin, a header's power pin) was not reserved, so a lead of another net could
  be placed in it, which on a real breadboard connects the two: in the 555 and 74HC595 test circuit an LED's anode was in the same strip as the 74HC595's supply pin, and no check said so. Every such strip is
  now respected, the check for two nets sharing a strip knows every pin of a physical part and also runs after the drawing, and a circuit that cannot then be laid out physically is laid out as a diagram, which
  pprender and ppbuild_instructions say on the error output (PACKPAY_PHYSICAL_ANCHORS=0 asks for it by hand). None of the seven example designs is affected, apart from knight-roller's pin lists.

Version 0.72.64 (2026-10-11)
=============================
* A passive part whose footprint is known not to plug into a breadboard (surface-mount, or leads off the 0.1 inch grid) now says so, with the sentence that an anchor's step carries, and the line under the
  title names it: "Insert the 100 resistor (R2): one lead into hole g2, the other into hole j17." was said of a surface-mount part too. knight-roller has ten such parts, rp2040 twenty-seven. A passive that
  plugs in, or whose footprint is not known, is worded as before.

Version 0.72.63 (2026-10-11)
=============================
* A part of kind lcsc whose fetch needs easyeda2kicad now ends in a clear message when that tool is not installed ("BT1: lcsc import failed -- cannot run easyeda2kicad ... (pip install easyeda2kicad)", exit status 1),
  where it used to end in a Python traceback. The manual page no longer says that such a part uses --kicad-cli, which it never did.

Version 0.72.62 (2026-10-11)
=============================
* make pdf now FAILS when LaTeX reports an error, and names it. Until now Org printed "PDF file produced with errors." for every document and the build succeeded, so a real error looked the
  same as the harmless one every document printed. That harmless one was a missing font: the shared preamble loaded Noto Sans Devanagari for all ten documents, though only Concept.org has
  Devanagari text (and a Concept.pdf built without the font has no Devanagari in it). The font is now declared by Concept.org alone, so on a machine without it the other nine documents build
  clean and only Concept fails, saying why. README says what make pdf needs.
* ResearchJournal.org had a regular expression outside code markup, which LaTeX rejected (an undefined control sequence) while the build said nothing; fixed.

Version 0.72.61 (2026-10-11)
=============================
* ppresolve_components has a --paper option, as ppkicad_layout has: the paper size to try first (A4, A3, A2, A1 or A0; default A4), each larger size still tried if the design does not fit.

Version 0.72.60 (2026-10-11)
=============================
* The instructions now say which pin is which for the parts that are not ICs. A connector or a cell wired straight to the rails names its pins on each rail ("Its pins on the power (+) rail: 1.
  Its pins on the ground (-) rail: 2."); a two-lead part names the pin of each lead after its hole ("hole b6 (pin S)") where the usual numbering (near lead 1, far lead 2) would be wrong: an audio
  jack whose pins are S and T, a two-pin connector whose near lead is pin 2. A resistor, an LED, an LDR or a switch is worded as before.
* As a result camera-trap and solar-roller are rebuilt from their own instructions with no pin_map at all, as the altimeter and knight-roller already were, and ppparse_instructions reads the new
  sentences. An instruction text written before this release still works, with the pin_map it needed.

Version 0.72.59 (2026-10-11)
=============================
* ppextract_sources writes its default symbols directory (STEM-symbols) next to the sources file given with -o, no longer in the current directory (with no -o, both are still written to the
  current directory). It refuses an output file in a directory that does not exist before writing anything. Until now a run from the source tree left a stray STEM-symbols directory there.
* make-archive refuses to build an archive that contains a top-level file or directory that Makefile.am does not name, and says which.

Version 0.72.58 (2026-10-11)
=============================
* make check runs the tests of the breadboard configuration again: 85 checks of the configuration reader and writer (the example boards, the default board, the multi-board geometry).
  They had been left out of make check since 2026-09-15 because three of their checks, on circuits of 1300, 1600 and 3200 passives, take over an hour each; those three now run only with
  pptest_breadboard_config --extreme, and the other fifteen take two seconds.
* The list of open issues (FutureResearch.org) was reviewed from end to end. It holds 24 open items instead of 62 headings, in an order that follows stated criteria (urgency, value,
  effort, and what blocks the item), and a test keeps it in step with the work.

Version 0.72.57 (2026-10-11)
=============================
* The step of a part that cannot be plugged into a breadboard because two of its pins would share a column (a two-row socket or header) no longer contradicts itself. It said "straddling
  the trench" and, a sentence later, that its pins were too close together to straddle it. Such a part is now placed "one pin per column" and its note reads "Its two rows of pins are only one
  hole apart, so two of its pins would share a column of holes and be shorted: it cannot be plugged into a breadboard as it is, so mount it on a breakout board or use a jumper lead for each
  pin." ppparse_instructions reads both the old and the new base sentence.

Version 0.72.56 (2026-10-11)
=============================
* A part whose pins cannot be plugged into a breadboard without two of them sharing a column of holes, and so being shorted together, is now said to be so. A two-row socket or header
  is such a part, whichever way it is turned: a pin of each row lands in every column. Its step ends with "Its pins are too close together to straddle the trench, so two of them would
  share a column of holes and be shorted: it cannot be plugged into a breadboard, so use a breakout board or a jumper lead for each pin.", and the line under the title names it. Until now
  such a part was left unmentioned, as if it plugged in; in the seven examples that is rp2040's two-row socket. Its layout is unchanged, one column per pin, which is what a breakout board or
  jumper leads give. ppparse_instructions reads the sentence.
* The concept document gains the best practice "Never let two pins of one part share a column of holes".

Version 0.72.55 (2026-10-10)
=============================
* The physical layout of single-row pin headers is now the default: a header stands in one row of holes, all its pins in the upper half in consecutive columns, pin 1 at the left,
  and the step says "standing in one row". PACKPAY_PHYSICAL_HEADERS=0 gives the diagram layout of the earlier releases. Of the seven example designs camera-trap, knight-roller and
  audio-jack change; the others are laid out exactly as before. A dual-row DIP has been laid out physically by default since 0.72.52. Only the two-row socket still follows the diagram.
* The line under the title that explains the pin holes now names only the two-row socket.

Version 0.72.54 (2026-10-10)
=============================
* Experimental, off by default: PACKPAY_PHYSICAL_HEADERS=1 places a single-row pin header in one row of holes, all its pins in the upper half in consecutive columns with pin 1 at
  the left, instead of across the trench with pins in both halves. The drawing shows a thin body with a square at pin 1, and the step says "standing in one row" and "Its pin 1 is at
  the left." Of the seven example designs camera-trap, knight-roller and audio-jack have headers and change; the others do not. The instructions of camera-trap and knight-roller
  rebuild every net.
* Fixed: the rails of a physical part (a DIP, and a header with the variable above) are on its own rail pins, inside the part. They were drawn beyond it, so a 3-pin header had a
  body five columns wide and a DIP's box was wider than the chip. The seven example designs are unchanged by this.

Version 0.72.53 (2026-10-10)
=============================
* A far lead now lands, nearest first on either side, in a column of its half that already holds its own net, instead of the first free column to the right. On a DIP the
  pins of the upper row run right to left, so the partner pin of a part hung on pin 3 is on the left and the old search cost a jumper wire; camera-trap's audio jack now goes
  into pin 4's own column and one jumper disappears. Only a net that is not a rail is concerned, and of the seven example designs only camera-trap changes. PACKPAY_FAR_LEAD_SIDES=0
  gives the earlier search.
* Fixed: a far lead next to column 1 of a second zone could be told to go into a hole that does not exist ("hole e100000"; rp2040's C14 did). It now stays on its zone.

Version 0.72.52 (2026-10-09)
=============================
* The physical DIP layout is now the default. A dual-row DIP is laid out where its footprint puts its pins (two in each column, the notch to the left, pin 1 in the lower
  row at the left) and the instructions say so; set PACKPAY_PHYSICAL_ANCHORS=0 for the diagram layout of the earlier releases, one column per pin. Of the seven example designs
  only camera-trap has a DIP: its PC817 now takes 2 columns instead of 4 and its instructions change; the other six are laid out exactly as before. Single-row headers and
  two-row sockets still follow the diagram.
* The line under the title that explains the pin holes now names a pin header and a two-row socket, the parts that still follow the diagram, instead of a DIP.

Version 0.72.51 (2026-10-09)
=============================
* A synthetic circuit with two real DIPs (an NE555 oscillator in a DIP-8 clocking a 74HC595 shift register in a DIP-16 that drives eight LEDs) is now part of the test
  suite, built from its own specification and put through the real tools with the physical DIP layout off and on. Both come back from their own instructions with no pin
  map and every net equal; with the physical layout the diagram is a fifth narrower and has no label overlaps, where the default layout has four. Nothing in the tools
  changed: the physical DIP layout is still off unless PACKPAY_PHYSICAL_ANCHORS=1.

Version 0.72.50 (2026-10-09)
=============================
* Experimental, off by default: setting PACKPAY_PHYSICAL_ANCHORS=1 places a dual-row DIP where its footprint puts its pins (two pins in each column, the notch to the
  left, pin 1 in the lower row at the left) in the layout, the drawing, the instructions ("Its notch faces left: pin 1 is in the lower row, at the left.") and the
  resolver. Tried on the PC817 of camera-trap (DIP-4) and on an LM358 (DIP-8), also on boards narrow enough to need a second zone: the connectivity, bounds, collision and
  label checks pass and the instructions rebuild every net. The whole test suite passes with the variable set as well as unset; with it unset nothing changes. It stays off
  by default until more DIPs have been through it.

Version 0.72.49 (2026-10-09)
=============================
* The build instructions now say which pin of a multi-pin part goes in which hole: "Its pins, from the left: 1 in a5, 2 in a6, 3 in f7, 4 in f8." They also
  name the pins on each rail: "Its pins on the ground (-) rail: 2." ppparse_instructions and ppresolve_components use them, so a schematic rebuilt from the
  instructions no longer needs a pin map for such a part: the altimeter and the knight-roller now come back from their own instructions with none. A pin
  map is still needed for a connector or a cell wired straight to the rails and for a two-pin connector whose pins are not numbered 1 and 2.
* The holes follow the diagram, one column per pin, which a real package does not (a DIP has two pins in each column): when a part that plugs in has its
  pins listed, a line under the title says to read the list as where each net goes, not as how to seat the part.
* A part whose only rail-like pin was an unconnected ground pin used to say that it connects to the power rail; unconnected pins are no longer counted.

Version 0.72.48 (2026-10-09)
=============================
* The build instructions now say which multi-pin parts do not plug straight into a breadboard. Each part's KiCad footprint is read: a surface-mount
  part is flagged as needing a breakout board, a through-hole part whose pins are off the 0.1 inch grid (a TO-92, a panel jack) as to be checked,
  and a part with no footprint on file as unknown. A part that does plug in (a DIP, a pin header) is worded exactly as before. A line under the
  title names the parts. Across the seven examples, of 30 multi-pin parts 9 plug in, 4 are off the grid, 7 are surface-mount and 10 have no
  footprint on file. ppparse_instructions reads both the sentence and the line.

Version 0.72.47 (2026-10-09)
=============================
* Documented, and pinned by tests, what the build instructions do not yet say about integrated circuits and connectors: which pin is where and which
  way round a part goes (pin 1, the notch). Measuring the seven examples showed that one more sentence cannot fix it: the layout gives every connected
  pin of a multi-pin part its own column, whereas a real dual-row package such as a DIP puts two pins in each column (camera-trap's PC817 spans 2
  columns, not the 4 the instructions name) and a single-row header stands in one half, not both. Of the 30 multi-pin parts in the examples, 13 are
  through-hole, 7 surface-mount and 10 have no footprint on file; only one is a classic breadboard IC.
* The concept document gains the best practice on orienting an IC (pin 1, the notch, counter-clockwise numbering) and the glossary entries DIP and pin 1.
  The instructions themselves are unchanged.

Version 0.72.46 (2026-10-09)
=============================
* A step no longer says the type of a part twice: "Insert the LED (D2)" and "Insert the D_Photo (D1)" instead of "Insert the LED LED (D2)" and
  "Insert the D_Photo D_Photo (D1)". A resistor's step ("Insert the 10k resistor (R1)") is worded as before, and the parser still reads
  instruction texts written with the old wording.

Version 0.72.45 (2026-10-09)
=============================
* A schematic rebuilt from build instructions now has every LED and diode the right way round. ppresolve_components reads the role the
  instructions name for each lead (the anode, the cathode, the positive or the negative lead), looks up the real symbol's pins by name,
  and puts each lead on the pin that says the same thing; before, an LED whose anode went in the first hole could come back reversed.
  The knight-roller round trip (schematic, instructions, schematic) now compares its LEDs and its photodiode exactly.
* Correction to 0.72.44: polarised capacitors were not actually recognised there, because KiCad names both of their pins "~". They are
  now, by the library's convention (pin 1 is the positive pin, confirmed against the drawing of the two symbols), so their steps name
  the positive and the negative lead and the rebuilt schematic puts them on the right pins.
* Not covered: a TVS diode array (its pins are named A1 and A2) and any symbol that names no polarity.

Version 0.72.44 (2026-10-09)
=============================
* The build instructions now say which way round the LEDs, diodes and polarised capacitors go. A step for a part whose pins are named as
  polar names the role of each lead and what tells the leads apart on the part, for example: "Insert the LED LED (D2): one lead into hole
  g18 (the cathode, the shorter lead on the flat side of the case), the other into hole j20 (the anode, the longer lead)." An LED's anode is
  the longer lead, a diode's cathode is the banded end, a capacitor's positive lead the one marked +. Resistors and other parts without
  polarity are worded exactly as before. ppparse_instructions reads the roles back.
* Not yet: which way round an integrated circuit or a connector sits (its pin 1) is still not described, and ppresolve_components does not
  yet use the roles when it rebuilds a schematic from the instructions.

Version 0.72.43 (2026-10-08)
=============================
* make check is now the sum of thirteen phases, check1 to check13, and each can be run alone (make check7). A run that is interrupted
  costs one phase instead of the whole suite; on an ordinary machine make check still runs them all, in order. pptest_regression
  gains --phases and --phase (a slice of its checks, balanced by their measured duration), --only, --list and --timings, and a
  registry of its check functions with a test that every one of them is in it.
* Split power rails are now read. Many current 830-point breadboards have rails that break in the middle (the sellers say most do;
  older boards, some versions and the maker's own boards do not). The configuration format could already say "continuous = false"
  but nothing read it. Now a board declared that way says so at the top of its build instructions and asks the builder to check each
  rail with a multimeter and bridge the halves with a jumper. A board that is not declared split says nothing: every existing
  instruction text is unchanged.
* The taxonomy of breadboards records what was found about split rails and about boards that join: clipping boards together is
  mechanical only, so the model's independent boards are right; where a rail breaks is not modelled.

Version 0.72.42 (2026-10-08)
=============================
* The classic board, the one the optimizer starts from when no configuration is given, is now 63 columns wide instead of 65: that is the
  number of strips on every full-size and double breadboard found in the sellers' listings. A layout for 63 fits a 65-strip board
  too. Measured first: all seven shipped designs lay out identically on either width. Boards you describe yourself in a
  configuration file are unchanged.
* The taxonomy of breadboards now records: three distribution buses on a double board (the model was right), more than
  five rows per half is a virtual board kept as a last resort, and split rails and joined boards are still to be explored.
* New research items: perfboard and stripboard, and the exploration of split rails and joined boards.

Version 0.72.41 (2026-10-08)
=============================
* A taxonomy of breadboards, in the concept document: the five properties that tell the real boards apart (strips per zone,
  zones per board, rows per half, power rails, how boards join), a table of the four classes sold (mini 170, half-size 400,
  full-size 830, double 1660 tie points) whose arithmetic a test checks, and how this project's ladder (a classic board, two
  zones, more boards) reads against it.
* The comparison found five things, none acted on, all listed for decision. The main one: the boards sold have 63 strips and
  the classic board here has 65; measured, every shipped design lays out identically on 63. Also: nothing sold has more than
  five rows per half, the sources disagree about the rails between the two zones of a double board, and the common boards'
  rails are split in the middle.
* A test keeps the taxonomy true to the project: its table must add up, and the two numbers it quotes (the classic board's
  width, the rows ladder) must be the code's own.

Version 0.72.40 (2026-10-08)
=============================
* A glossary of terms, at the end of the concept document (Concept.org), 51 entries: the breadboard words (zone, strip,
  column, row, rail, anchor, passive, jumper, link, ...), the schematic words (sheet, net, symbol, unit, ...) and the
  project's own (build instructions, the loop, A/B, oracle, ...). The workflow document points to it. It settles where this
  project's words differ from the usual ones: its column is what many makers call a row, and its zone is what vendors call a
  terminal strip. A test checks that every code name the glossary cites still exists.
* The best practices for breadboards and schemes, in the concept document: 12 and 9 practices, each with its reason, its sources
  (which do not always agree, and the section says so) and what this project does about it: guarded by a named test, encoded in
  the code, still open, or outside the tool. Seven are still open, among them split power rails, wire colours, which way round an
  LED goes, and decoupling capacitors; they are listed as research items. A test keeps the section true to the project.

Version 0.72.39 (2026-10-08)
=============================
* The optimizer now starts from a real, classic breadboard: 5 rows per half, 65 columns, one zone. If the circuit does not fit,
  it tries 2 zones, then more boards added one at a time (each with 1 zone, then 2), and a taller board (more than 5 rows
  per half) only as the very last resort. A configuration you give is always the starting point and is never narrowed.
* rp2040 now comes out as 2 zones of 5 rows per half and 65 columns, instead of a one-zone board 93 columns wide that does
  not exist. The six other examples are byte-for-byte unchanged.
* The build instructions now say which zone a hole is in ("hole a5 (zone 2)"), and the header says the board has 2 zones.
  Before, two parts could be told to go in the same hole. ppparse_instructions and ppresolve_components read the marker.
* The layout reports how left-heavy it is (the share of holes in the left half of its span). It only reports for now.

Version 0.72.38 (2026-10-07)
=============================
* Breadboard layout: the knight-roller example now fits a standard 5-row-per-half board (it needed 10), and
  rp2040 does too (it needed 7). The layout spreads parts across more columns and uses more jumper wires
  instead of stacking them in one column or asking for a taller board. The five other examples in the comparison are
  unchanged, byte for byte; example-circuit1 now also fits the default board (it overflowed by 2 holes).
* Fixed on the way: a jumper wire no longer lands past the end of a column when free holes remain (the hole
  next to the trench counts); a net spread over several columns is joined as a chain when one column cannot
  take all the wires; a column reserved for one net's part can no longer be taken by another net's part; a part
  label can no longer be printed outside the board.
* The busier layouts show that labels now sit farther from their parts in some cases (knight-roller, rp2040).

Version 0.72.37 (2026-10-07)
=============================
* Breadboard diagrams: a jumper wire's arc no longer leaves the board. A long arc used to bulge past the
  board's top or bottom edge (the altimeter, dudhya and knight-roller examples did); it is now shortened, or
  drawn the other way round, so it stays on the board. An arc that already fit is unchanged.
* Breadboard diagrams: a part's label is no longer printed on top of a power rail line (dudhya's D2 and R3,
  knight-roller's D6, rp2040's C4 were). The label moves to the nearest free spot instead.
* Measured on every small example from the diagram's own SVG text; three examples (solar-roller, camera-trap,
  audio-jack) are byte-for-byte unchanged.

Version 0.72.36 (2026-10-07)
=============================
* The knight-roller example now goes all the way round: schematic, build instructions, and back to
  a schematic (ppextract_sources, ppbuild_instructions, ppresolve_components). Running it found
  four problems, three of them fixed here.
* IMPORTANT, a correction to the build instructions: the breadboard layout used to treat any
  net with more than four members as a power rail. In knight-roller two LED matrix lines
  qualified, and the instructions told you to put the leads of two LEDs on the + rail at both
  ends, shorting those lines to the supply. Only power nets (a conventional name such as GND or
  VCC, or a power pin) are wired to the rails now; the others get jumper wires. knight-roller needs a
  bigger board (10 rows per half) and 32 steps instead of 28. The schematic output is unchanged.
* When a design needs a bigger board than the default, the instructions now say so, right
  after the title ("Board: 7 rows per half (rows a-g above the trench, h-n below)."), and
  ppparse_instructions and ppresolve_components read it. A board configuration that contradicts it
  is refused with a message instead of silently misreading the holes.
* ppresolve_components: a pin_map value may be a list of pins, for a part with several pins on one
  net (an IC with two grounds): all of them join the net. Before, only one did.
* Fixed: in the knight-roller breadboard layout one resistor's far lead stood inside the leg of the LED
  attached to it (a lead on another component's wire). A pass that shifts a part within its column did not
  re-check the parts attached to its far column. Six other example layouts are byte-for-byte unchanged.
* A part whose far lead has no free column in a dense layout is now refused with a message,
  instead of being drawn into a column that shorts two nets (the diagram's own guard used to catch
  it afterwards, with a less helpful message). The 200-part coldfire demo is refused this way on a
  17-row board; it also had seven signal nets wired as power rails.
* Not fixed, recorded: the instructions still do not say which lead of an LED or diode is the
  anode.

Version 0.72.35 (2026-10-07)
=============================
* New command: ppextract_sources SCHEMATIC. It writes the symbols a KiCad schematic embeds
  (one library file per nickname, the symbols of included sheets too) and a sources file for
  ppresolve_components whose entries point at them, with an empty pin map for you to fill (only
  you know which pin is which). A design that predates a library rename, such as the camera-trap
  example (Conn_01x03_Male, no longer in KiCad 10's Connector library), can only be resolved
  from its own embedded symbols. Where the schematic and an installed library both have a
  symbol, the schematic's own is used; a part found in neither is reported as a warning. The
  error message of ppresolve_components for an unusable sources entry now names the command.

Version 0.72.34 (2026-10-07)
=============================
* ppresolve_components: a resistor, capacitor, inductor, diode or other standard-library
  passive now comes back from the build instructions with its own value ("10k"), not with the
  type word attached ("10k resistor"), which used to be printed on the schematic symbol. The
  build instructions say "Insert the 10k resistor"; the word "resistor" is now taken off again.
  (The earlier loop tests compared connections only, so this had gone unnoticed.)

Version 0.72.33 (2026-10-07)
=============================
* ppresolve_components: a sources entry that cannot be used (the symbol is not in the given
  library file, the file does not exist, or the entry lacks lib, part or sym_path) now ends the
  run with ONE clear message that names every affected part, and exit status 1. Before, it
  ended in a Python traceback, one part at a time. The message says that sym_path must point at
  a file that contains the symbol, and that a design predating a library rename keeps the old
  symbol name only in its own schematic.

Version 0.72.32 (2026-10-06)
=============================
* A part's far lead on a power net that is fed by a source attached directly to a rail,
  where no other member of the net has a place on the board's columns, is now wired to
  that rail, in the diagram and in the build instructions ("the other into hole e14 (on
  the nearby power (+) rail)"). In the camera-trap example, the switch's far lead was
  connected to nothing. Every other example is unchanged.

Version 0.72.31 (2026-10-06)
=============================
* A part is no longer taken for a power source just because it sits between two
  rail-like nets and comes from a project's own symbol library. The exclusion of
  generic passives (resistors, capacitors, inductors, ferrite beads, diodes, LEDs,
  crystals, transistors) used to look the part up in the standard library only; it
  now decides by the reference prefix or the part name, with at most 4 pins, from any
  library. On KiCad's coldfire example 104 of 160 parts were wrongly "power sources"
  and now 13 are; on complex_hierarchy 25 and now 8. These verdicts decide which part
  is placed first and the role the build instructions give each part. The solar-roller's
  two light sensors and the knight-roller's photodiode are no longer power sources.
  Switches, jumpers and connectors are deliberately still considered, since a terminal
  block or a jumper can feed power.
* A drawing of a breadboard no longer depends on what was drawn before it in the same
  process (the command-line tools, one circuit per process, were not affected).
* Known, not fixed: a part's far lead on a rail-like net whose other members are
  attached directly to a rail gets no wire, in the diagram or the instructions.

Version 0.72.30 (2026-10-06)
=============================
* The breadboard build instructions were incomplete for some circuits. The diagram
  showed a wire from a part's far lead to the rest of its net, but the instructions
  never said to place it, so following them left that net open. The wire is now a
  step of its own (one per pair of strips, not one per part), and the checker that
  should have caught it now counts those leads for missing connections, not only for
  accidental shorts. Instructions that were already complete are unchanged
  (byte-identical for the altimeter and the solar-roller); the camera-trap and the
  dudhya battery-free example each gain one jumper.
* Round trip: a dual op-amp with a bypass capacitor now goes schematic ->
  build instructions -> schematic and comes back with every net of the source.
* ppresolve_components: a power rail and the circuit's own name for the same node
  (VBUS and VCC on one pin) are one net; two different ordinary names, or two
  different rails, on one pin are still refused.
* Known, not traced: a layout can depend on which circuit was laid out earlier in the
  same process (it is not an issue for the command-line tools, which run one circuit
  per process).

Version 0.72.29 (2026-10-06)
=============================
* ppresolve_components: two nets that contain the same physical pin are now one
  net. A pin tied to a power rail and also stated by number in the instructions
  (a bypass capacitor's lead "also connecting to U1's own pin 4") used to be two
  nets on one pin and the layout was refused. Two nets that both carry a real
  name on one pin (VBUS and GND both mapped to pin 4 by a wrong pin map) are
  refused, naming both, never merged.
* Found, root cause known, NOT fixed: the generated build instructions can leave
  a net open where a part's far lead should join it, and the checker that should
  catch it looks at those leads for accidental shorts but never for missing
  connections. It affects a small circuit built to test it, and a first
  measurement found it in two of the shipped example circuits as well; the fix
  will make the checker refuse circuits it accepts today, so it is left for a
  decision.

Version 0.72.28 (2026-10-06)
=============================
* ppresolve_components (the build-instructions route) now lays out a part whose
  symbol has several units, such as a dual op-amp, unit by unit, as
  ppkicad_layout does: each unit the design uses is its own symbol with its own
  pins, under the part's real reference. Checked on a schematic -> build
  instructions -> schematic loop.
* Any refusal in that route (two labels on one point, a drawing that would join
  two different nets) is now a clear message and exit status 1. Before, it
  escaped as a Python traceback; the earlier note that such a part was "refused
  cleanly" was wrong -- it had not been run.
* Known, not yet traced: a rail pin and a pin stated by number that resolve to the
  same real pin stay two nets, and the generated instructions can omit a jumper
  for a net with several members. Both are recorded.

Version 0.72.27 (2026-10-06)
=============================
* A row of parts tied only to the power rails (decoupling capacitors, a
  battery) is now placed clear of every other part on the sheet, also under a
  wide, shallow chip, where it could previously be refused as overlapping at
  every paper size. A layout that already worked is unchanged.

Version 0.72.26 (2026-10-06)
=============================
* Parts whose symbol has several units (a dual op-amp, a quad gate) are now
  laid out one unit at a time by ppkicad_layout: each unit the design uses is
  placed as its own symbol, with its own pins, under the part's real
  reference. Before, all units were treated as one symbol whose pins sat on
  top of each other, so two different nets' labels landed on the same point.
  A pin drawn in several units (the power pins of many op-amps) is connected
  in each of them.
* The three real designs that could not be generated at all now come back
  from KiCad with exactly the source's connectivity, every value, and no
  electrical-rule errors: the RP2040 design (35 parts), KiCad's own
  complex_hierarchy example (68 parts, two op-amps, a sheet used twice -- kept
  as one shared sheet), and KiCad's coldfire example (160 parts).
* Not yet: ppresolve_components (the instructions route) does not lay out
  multi-unit parts unit by unit; such a part is refused with an error, never
  written wrong.
* Documents now credit Claude Sonnet 5.5 as the assistant.

Version 0.72.25 (2026-10-05)
=============================
* IMPORTANT FIX: some schematics written by earlier versions were electrically
  wrong, with no warning (KiCad's own electrical-rule check does not report
  it). Found by comparing a generated schematic with the netlist of the
  design it came from, which the test suite had not done for these cases:
  (a) a direct wire between two parts could run straight over a third pin,
  shorting it -- the bundled example circuit 1 had a shorted capacitor in
  every version up to 0.72.24; (b) a wrapped row of many decoupling
  capacitors could short the supply to ground; (c) on a tall chip such as an
  RP2040, the short connection stubs of neighbouring pins could overlap and
  merge unrelated nets. All three are fixed, and the generator now checks
  the drawing itself and REFUSES to write a schematic that would join two
  different nets.
* Real designs that could not be laid out at all now can. A 35-part design
  built around an RP2040 now comes back from KiCad with exactly the source's
  connectivity. Causes fixed: a label running past the LEFT edge of the sheet
  (no paper size can cure that; the left margin now widens by the measured
  amount); two parts placed on top of each other; large chips placed too close
  to their neighbours; wrapped rows of parts packed too tightly.
* --row-gap and --anchor-spacing are now MINIMUMS: the generator raises them
  where a part's own size needs more room, and leaves a layout that already
  worked exactly as it was.
* Known, recorded for a future release: a part with several units (a dual
  op-amp) is still placed as one unit, which blocks some designs; two sheets
  of KiCad's own coldfire example still do not fit.

Version 0.72.24 (2026-10-05)
=============================
* ppkicad_layout now keeps a reused sheet reused. When the source design
  uses one sheet file more than once (the same sheet instantiated by several
  sheet symbols, as in KiCad's own complex_hierarchy example), the new
  schematic has one child file for it and several sheet symbols, each instance
  keeping its own reference designators, instead of an independent copy per
  instance. The parts of the instances are matched by the identifiers they
  have in the source, and the match is verified (same parts, values and
  connections); anything that cannot be shown identical is written as
  independent sheets, as before. Checked with KiCad's own tools: the same
  references per instance, the same connectivity, no electrical-rule errors.
* Not covered: identical sub-circuits that the source does not declare as
  reuse (a flat design with several identical channels) are not detected; and
  reuse below the top level, of a sheet that holds sub-sheets, or of a sheet
  with a power-flag, is written as independent copies.
* Known: KiCad's own complex_hierarchy example can be recognised but still
  cannot be generated end to end (it fits on no paper size), so generation was
  validated on a small hand-written design.

Version 0.72.23 (2026-10-05)
=============================
* ppkicad_layout: a design that is itself hierarchical now stays
  hierarchical. The netlist's own sheet structure is followed: one
  child sheet per sheet of the source, named after it (usb-power,
  flash...), nested as the source is nested, with the parts of the
  source's own top sheet on a child called Root -- however small the
  design, and without being asked. A source sheet bigger than
  --max-components is split inside itself. --flatten gives the old
  behaviour: one sheet, split only above the limit. A design with no
  sheet structure (a flat one, or one built by hand or from build
  instructions) is unaffected.
* ppkicad_layout reads the symbols embedded in the input schematic
  itself (and in every sheet file it includes), so a schematic no
  longer needs --symbol-lib for a project's own library, and a symbol
  that has since been renamed or removed in KiCad's libraries still
  resolves: the symbol its author drew with is the one used. An
  explicit --symbol-lib still wins; a .net file carries no symbols, so
  it still needs the option.
* Fixed: a symbol defined as an extension of another one (many
  microcontroller variants are) was written into the new schematic
  without its pins, so KiCad saw a part with no pins and every one of
  its connections came out missing. It is now written complete.
* The netlist loader now records which sheet of the source design each
  part sits on, and the design's list of sheets.
* Known, recorded for a future release: one real hierarchical design
  (rp2040-basic-m1) still fits on no paper size in any mode; changing
  the left margin alone does not cure it.

Version 0.72.22 (2026-10-05)
=============================
* New command-line tool, ppkicad_layout: reads a KiCad schematic (or
  a netlist exported from one) and writes a new, automatically laid-
  out schematic of the same circuit. A large circuit is split across
  a root sheet and child sheets, with every file written reported;
  the per-sheet size is --max-components, the starting paper size
  --paper. Components from KiCad's standard symbol libraries need
  nothing further; a component from a project's own library is
  supplied with --symbol-lib. This is the direct route from an
  existing design to a new one that the workflow documentation had
  listed as missing, and the command ppnetlist's help text had
  pointed at without it ever existing. The result was checked with
  KiCad's own tools: the same components and nets as the input, no
  electrical-rule errors, for a single sheet and for a split design.
* Fixed: a component whose symbol library was not in KiCad's standard
  directory used to be skipped without a word, and the run then
  stopped later with an obscure internal error ("no PINS entry
  found"). It is now reported up front, naming the library, the
  components that use it, and what to supply.
* Documentation: the workflow guide's section on this step now
  describes the tool; ppnetlist's help gives the actual KiCad export
  command instead of a pointer to a page that did not exist.
* Packaging: the archive script's check that tools are still
  executable now covers more of them.
* Known, recorded for a future release: ppresolve_components still
  lays its main components out in alphabetical rather than
  connectivity order, which can make a small circuit fail to fit one
  sheet at any paper size; the new tool does not have the problem.

Version 0.72.21 (2026-10-05)
=============================
* Fixed a case where a large circuit split across several levels of
  KiCad sheets (a sheet that itself had to be split further) was
  written with incomplete sheet connections: KiCad's own checker
  rejected it with "sheet pin has no matching label inside the sheet"
  errors, even though the connections themselves were electrically
  right. Such multi-level designs are now complete, and were verified
  for the first time by writing them to disk and reading them back
  with KiCad's own tools, at two and at three levels deep. A new
  automated test keeps it that way. Circuits that fit on a single
  level of sheets are unaffected.
* Packaging: the release archive is again built with the project's
  own archive script, so every file sits at the archive's top level
  (0.72.20's archive had been built with a different tool, which put
  everything inside a version-named folder). A stray KiCad check
  report that had been included in releases 0.72.7 through 0.72.19 no
  longer ships, and two example files for the altimeter test circuit
  that had been removed in error are back.
* Documentation: the development standard now spells out the delivery
  procedure step by step (including keeping the session handoff note
  current at every delivery), and a rule about not leaving scratch
  files in the project folder. The handoff note itself, untouched
  since 0.68.0, is brought up to date.

Version 0.72.20 (2026-09-29)
=============================
* A large, dense circuit that doesn't fit on any single schematic
  sheet, at any paper size, now automatically splits into multiple
  sheets to make room, the same way an oversized circuit already did
  by component count alone -- and if one of THOSE resulting sheets is
  itself still too dense, it now splits further too, recursively, as
  many times as the circuit genuinely needs.
* Fixed three separate, underlying issues found while building and
  testing this: a sheet could end up with a net that had no way to
  reach the main schematic above it; a component correctly identified
  as not needing a connection point could be wrongly flagged as
  unplaceable once a sheet was split into smaller pieces; and
  generating a sheet containing only certain power-related components
  could crash outright in that same situation.
* A further, separate issue was found testing against a real device
  with a battery: in one specific case, a component could end up
  positioned too close to another, overlapping it. This is being
  tracked for a future release rather than rushed.

Version 0.72.19 (2026-09-29)
=============================
* Fixed two cases where generating a split, multi-sheet KiCad
  schematic could refuse a large, real-world circuit outright, even
  though every part in it genuinely had somewhere valid to go: a
  component whose only connection is to a shared supply/ground rail
  could be wrongly reported as unplaceable in some cases; and two or
  more components that are only ever wired to each other (and
  otherwise only to rails), with no path to any of the circuit's
  main components, are now placed together in their own dedicated
  area of the sheet instead of being refused.
* Two further, harder issues were found while testing this against a
  large, real demo circuit and are being tracked for a future
  release rather than rushed: that same large circuit still doesn't
  fit cleanly on any single sheet size tried, and a separate,
  internal heuristic for recognizing certain components can be
  fooled by circuits that use their own custom parts library rather
  than the standard one.

Version 0.72.18 (2026-09-29)
=============================
* Fixed a case where, on a sufficiently dense, tight breadboard
  layout, a component's far-side connection could occasionally land
  on top of a different component's pin entirely, producing a silent
  electrical short between two unrelated connections rather than a
  clearly reported problem. A related, deeper case (requiring the
  layout to reserve more room upfront for certain multi-way
  connections) remains open and is noted as such for a future
  release.

Version 0.72.17 (2026-09-29)
=============================
* Fixed a case where a breadboard jumper wire connecting to a far
  connection point that had already been reserved for it (during an
  internal "I'll need this column later" bookkeeping step) could end
  up pointing at the wrong spot entirely once the diagram was
  actually drawn -- the two steps weren't talking to each other. A
  related case, in the same area, could also cause a second, genuine
  lead to land on top of a different component's own lead when that
  same reservation was involved. Both are now fixed directly.
* Generation of breadboard instructions now automatically retries
  with a taller board when the one being used doesn't have enough
  vertical room for a circuit, the same way it already retries with
  more boards side-by-side. Most real breadboards have 5 rows per
  half-strip, so that's tried first; a taller board is only tried if
  that genuinely isn't enough.

Version 0.72.16 (2026-09-29)
=============================
* Fixed a case where a component's far breadboard connection could
  land off the edge of the board entirely, producing a nonsensical
  hole reference in the generated instructions, when that component
  sat at the board's own leftmost column and the preferred nearby
  position was already occupied. A similar case (a different code
  path) was fixed in a previous release; this closes the remaining
  gap in the same general area.

Version 0.72.15 (2026-09-29)
=============================
* Fixed the USB-C connector connection issue noted as known in the
  previous release. The real cause: some connectors have two
  differently-named pins at the exact same physical location (for
  example, redundant power pins for better current handling). When
  only one of the two was actually used, generation could mark that
  shared location as "not connected" even though a real connection
  was correctly drawn there -- silently dropping it. This is now
  handled correctly.

Version 0.72.14 (2026-09-29)
=============================
* A component tied only to power/ground rails (such as a decoupling
  capacitor, or a battery) can now be placed when generating a KiCad
  schematic. Previously this failed outright for any circuit with
  such a part -- which is most real circuits -- unless it was the
  one, single power source. These components now get their own row
  on the sheet, separate from the rest of the circuit.
* Fixed a related, separate bug: two components' connection labels
  could, in rare cases, end up drawn at the exact same point on the
  page, which is silently read as one shared connection instead of
  two separate ones. This is now detected and refused outright, with
  a suggestion for how to resolve it, instead of producing a wrong
  schematic. Two new options, --row-gap and --row-spacing, are
  available to adjust spacing if this occurs.
* Known, not yet fixed: a rare case where a component's connection
  to a USB-C connector can be silently dropped when generating a
  schematic, even though the component itself is placed correctly.
  Tracked for a future release.

Version 0.72.13 (2026-09-29)
=============================
* Fixed a real bug that could cause two different power/ground
  rails to be wired together on the same breadboard column when a
  component's far connection was assigned automatically -- a
  genuine short, not merely a cosmetic issue. This has been possible
  since automatic rail-attachment was added; it is now fixed, and a
  permanent test guards against it recurring. The circuit-
  verification step that is supposed to catch this kind of problem
  had the same underlying mistake and so never flagged it either;
  that is fixed too.

Version 0.72.12 (2026-09-29)
=============================
* Fixed a correctness bug in how a component's connection to a
  power or ground rail is reconstructed from build instructions.
  Previously, if only the near end of a part (like a decoupling
  capacitor) was recognized as touching a rail, the far end's
  connection to a different rail could be silently lost or
  scrambled when regenerating a schematic. Both ends are now
  tracked correctly, and parts sharing the same rail are joined
  into one connection as expected.
* Found and documented, but not yet fixed, a separate, real issue:
  under some circumstances two components attached to different
  supply rails can end up sharing the same physical breadboard
  column, which would short those rails together. This has been a
  latent possibility since rail-attachment support was added; it is
  now tracked as its own item for a future fix.

Version 0.72.11 (2026-09-28)
=============================
* Circuits too large for one KiCad sheet are now split across
  several instead of being refused. The tool writes a top-level
  sheet plus one file per sub-sheet, connects them with proper
  hierarchical pins, and keeps every net's name exactly as it was.
  On the test circuits the split design is electrically identical
  to the single-sheet one, with no ERC errors.
* ppresolve_components: --max-components is now the per-sheet limit
  for the KiCad output. Above it you get OUTPUT.kicad_sch plus
  OUTPUT-sheet1.kicad_sch, OUTPUT-sheet2.kicad_sch and so on, and
  every file written is reported. (Before, a circuit above the limit
  was refused.)
* Known limit, not new but now recorded: a part connected only to
  power rails (a decoupling capacitor, say) still cannot be placed
  on the KiCad side, on one sheet or several. The tool refuses
  cleanly and names the part. See FutureResearch.org.

Version 0.72.10 (2026-09-28)
=============================
* Second step toward splitting very large circuits across several
  KiCad sheets: the part that decides which components go on which
  sheet. It keeps each main chip together with its own small parts,
  balances the sheets rather than filling one and leaving a stub,
  and reports which connections cross between sheets. On a real,
  160-component design it needs 20 crossing connections where a
  naive split needs 76. No user-visible change yet: nothing calls
  it until the next release.

Version 0.72.9 (2026-09-28)
============================
* First step toward splitting very large circuits across several
  KiCad sheets. Confirmed that KiCad's own command-line tools read
  back a multi-sheet design written in this project's own format
  correctly, with every net keeping its exact name, and added the
  building blocks for writing one (a root sheet, sheet symbols with
  real hierarchical pins, hierarchical labels on the child sheets).
  A permanent test now guards against this ever breaking in a
  future KiCad version. No user-visible change yet: the splitting
  itself follows in later releases.

Version 0.72.8 (2026-09-24)
============================
* Documentation only, no code changes. Clarified and wrote down,
  for the first time, the full set of project-tracking states this
  project's documents already use (not yet started, actively being
  worked, paused but not finished, resumed, done, abandoned) and
  when each applies. Applied this consistently across the open-
  issues list, and removed a few more entries whose outcomes are
  now fully on record elsewhere.

Version 0.72.7 (2026-09-24)
============================
* A battery or other simple, two-terminal power source that
  connects directly to a breadboard's power rail can now also be
  turned back into a KiCad schematic, not just a breadboard layout.
  The tool figures out on its own which of the part's two
  connections is positive and which is ground, by reading the
  part's own labeled pins (works automatically for common battery
  and cell symbols); for a part whose pins aren't labeled clearly
  enough to tell, it asks for that one detail explicitly instead of
  guessing.
* Project documentation cleaned up: finished items are now removed
  from the open-issues list once their outcome is on record
  elsewhere, so that list stays focused on what's actually still
  open.

Version 0.72.6 (2026-09-23)
============================
* Fixed a long-standing placement limitation: when a component's
  own wiring needed a connection back to a crowded part of the
  board with no room left for it, the layout would occasionally
  fail outright instead of finding another way. The engine now
  looks for a roomier spot elsewhere on the board and bridges the
  connection with an extra jumper wire, the same way an experienced
  builder would work around a crowded spot on a physical
  breadboard. Verified against every one of this project's own
  standard test circuits and board layouts, plus the original,
  more demanding real-world circuit that first surfaced this
  limitation, with no loss of quality anywhere else.
* A narrower, related case (a connection needing more than one
  such bridging wire from the same crowded spot) remains open for
  a future release.

Version 0.72.5 (2026-09-23)
============================
* Documentation only, no code changes: the project's own research
  notes document had one section that had grown to roughly a third
  of the whole document with no internal structure at all, making
  it very hard to find anything inside it. Split into ten properly
  labeled, individually findable sub-sections.

Version 0.72.4 (2026-09-23)
============================
* Fixed: when regenerating a KiCad file from build instructions, a
  chip pin that needs external power now automatically gets the
  usual KiCad marker confirming it's meant to be driven, instead of
  silently leaving behind an electrical-check warning about it.
* This surfaced that the marker-placement feature itself, though
  already present, had apparently never actually worked correctly at
  all -- two further, related bugs found and fixed along the way, with
  new test coverage added to catch a repeat.

Version 0.72.3 (2026-09-22)
============================
* Fixed a bug where a component whose connection to a larger chip or
  connector was only implied by sharing a physical spot on the
  breadboard (never spelled out explicitly) could, in rare cases,
  silently end up wired to the wrong pin of that chip when
  regenerating a KiCad file from build instructions. The generated
  instructions now state this kind of connection explicitly, so
  nothing needs to be guessed; a narrower, more cautious fallback
  remains for instruction sets created before this fix, which now
  refuses to guess at all rather than risk getting it wrong.
* Found during this same work: a mismatch between two related
  checks used elsewhere in this same fallback -- self-corrected
  before release, with test coverage added to catch a repeat.
* Documentation: recorded two findings from the previous release
  that weren't yet written up, and noted a newly discovered, unrelated
  gap (a missing electrical-check annotation on some regenerated
  circuits) for future investigation.

Version 0.72.2 (2026-09-22)
============================
* Fixed a bug where the generated build instructions could
  incorrectly claim a component was connected to a power rail when
  it wasn't -- caused by an overly broad name check that matched a
  voltage value anywhere in a signal's name (e.g. a regulator's own
  4.2-volt output, named accordingly), not only when a net's whole
  name was a rail's voltage label. Found running this project's own
  full schematic-to-instructions-and-back loop against a genuinely
  new, real power-supply circuit.
* Confirmed a known, already-documented board-sizing limitation
  applies more broadly than first written down: a very small board
  can run out of room for even a single connecting wire, not only
  when several such wires are needed at once. No behavior change --
  this is a documentation correction, not a new restriction.

Version 0.72.1 (2026-09-21)
============================
* Generating a new KiCad file from a set of instructions now
  accepts the same board-layout option as generating the
  instructions themselves, keeping the two consistent. This closes
  the gap noted in the previous release: instructions generated
  against a non-standard board layout used to be silently,
  incorrectly read back using the standard one instead.
* Found and fixed a real gap in this project's own test coverage:
  the previous release's own new test for the "implicit connection"
  fix had been written and verified, but was never actually wired
  into the main test run -- so it never once ran as part of a real,
  full check despite being reported done. Fixed, and both this and
  the new test for the board-layout fix above now run as part of
  the real suite.
* FutureResearch.org now carries an up-to-date summary of every
  genuinely still-open issue, in a considered order, kept current at
  every delivery going forward.

Version 0.72.0 (2026-09-18)
============================
* Closed the last two issues from 0.71.0's own issue set, closing
  that whole set:
  - A component whose symbol reuses another's pin layout (a common,
    standard practice for related parts) can now be read correctly
    -- it used to be unreadable, requiring a manual workaround.
  - A component whose real-world wiring is only implied by sharing
    a physical connection point with another part -- never spelled
    out explicitly -- is now correctly recognized when generating a
    new KiCad file from a set of instructions, instead of being
    reported as impossible to place.
* Found and fixed a real bug in this project's own internal caching:
  a fix applied to a circuit's connections wasn't always being seen
  by the very next step that needed it.
* Found, but not yet fixed, a related gap: generating a new KiCad
  file from instructions doesn't yet let you specify a custom board
  layout the way generating the instructions themselves does -- it
  silently assumes a standard one instead. Documented for a future
  fix.

Version 0.71.2 (2026-09-17)
============================
* Closed the third issue from 0.71.0's own issue set: a part placed
  right at the edge of a breadboard could, in some cases, end up
  with a nonsensical, unusable connection point described for its
  other leg. It now always gets a genuine, valid one instead.

Version 0.71.1 (2026-09-17)
============================
* Closed the first two issues from 0.71.0's own new issue set:
  - A passive whose far leg genuinely can't be placed at all now
    says so honestly in the generated instructions, instead of
    silently, misleadingly repeating its near leg's hole a second
    time.
  - A power source is now only ever wired directly to a board's
    rail when it's a genuine, simple source (both its own
    connections are power/ground) -- not when it's actually a motor
    or a sensor that merely happens to draw power from the same
    rail, which used to get the same treatment by mistake.
* Also found and fixed a real bug in this project's own test suite
  itself: some test runs were silently corrupting each other's
  results by not resetting shared internal state between them. This
  explains why one of the original issues looked less reproducible
  than it actually was -- re-verified against a case that
  genuinely, reliably reproduces it instead.

Version 0.71.0 (2026-09-17)
============================
* Ran the full schematic-to-instructions-and-back loop against a
  second, genuinely different real circuit (solar-roller, not the
  altimeter), on purpose, to find what a single example couldn't --
  found six separate, real bugs and gaps along the way, from
  misleading generated instructions to a KiCad symbol format this
  project couldn't read yet. None fixed in this release -- they're
  written up in FutureResearch.org, in a deliberate order, to be
  addressed one at a time. This project isn't considered complete
  until this loop runs flawlessly in both directions.
* No code changes in this release -- documentation only
  (ResearchJournal.org, FutureResearch.org).

Version 0.70.0 (2026-09-17)
============================
* Workflow.org, the walkthrough from a schematic (or build
  instructions) to a breadboard diagram or a new KiCad schematic, now
  uses this project's own actual command-line tools throughout,
  start to finish, on one real, consistent example circuit -- no raw
  Python code shown anywhere in it anymore.
* Found and fixed an oversight: three scratch working directories
  had ended up in the 0.69.0 delivery archive without being asked
  for. Removed, and a new, explicit rule about this added to
  DevelopmentStandard.org, so it doesn't happen quietly again.
* The altimeter example circuit used throughout Workflow.org now has
  a proper home: TestSchemes/PoorManAltimeter/, alongside this
  project's other real, worked examples.

Version 0.69.0 (2026-09-16)
============================
* Fixed a real gap in the default build-instructions format: it
  could never be read back by the reverse tools at all, out of the
  box, until now.
* A genuine, simple power source (a battery, for example) is now
  placed the way a real person actually wires one -- directly on a
  board's rail system, distributing from there -- instead of
  sitting on the main grid right next to another component. Applies
  automatically whenever the board has a rail configured; falls
  back to the previous behavior otherwise.
* New, dedicated, automated test coverage for both of the above.
* Documented the full, verified, command-line workflow for going
  from build instructions back to a breadboard or a new KiCad
  schematic, including this new placement strategy and its current,
  known limits.

Version 0.68.0 (2026-09-15)
============================
* Build instructions can now state an anchor's own power/ground rail
  connections and its power-source role (primary or secondary), in
  both directions -- the generator states them in prose, and the
  reverse parser reads them back to correctly reconnect an anchor's
  rail pins on the reconstructed circuit. This closes a known gap
  where, for example, a sensor's power pins would come back
  disconnected after a round trip through build instructions.
* New, dedicated, automated test coverage for this, and for the
  reverse instruction parser generally, which had none before.

Version 0.67.0 (2026-09-15)
============================
* Traced a long-standing, severe performance issue on very large,
  synthetic circuits to its exact, complete mechanism: components
  landing on consecutive columns trip a visual-crowding check
  (run_declutter) that cascades through the relocation logic
  (relieve_overflow), round after round.
* Rather than a risky algorithm change, added a sensible default
  limit on circuit size instead -- grounded in how many components
  actually fit on a real breadboard, and in this project's own
  real-world circuits (6-50 components). Circuits over that limit
  are now refused immediately, with a clear message, on both the
  breadboard and the KiCad-schematic side; raising the limit
  explicitly still works, with a warning.
* New --max-components option on every affected tool
  (ppauto_layout, pprender, ppbuild_instructions,
  ppresolve_components).

Version 0.66.0 (2026-09-14)
============================
* The delivery archive's own layout is back to how it always used to
  be: every file sits directly at the top level again, instead of
  being nested one folder down. (This had quietly changed for the
  last three releases -- 0.63.0 through 0.65.0 -- while fixing an
  unrelated packaging bug; caught and reverted this release.)

Version 0.65.0 (2026-09-11)
============================
* Every step of the complete loop -- turning build instructions back
  into a working KiCad schematic -- can now be run as its own,
  standalone command-line tool, matching the rest of this project's
  tools exactly: one to inspect what was recovered from a set of
  instructions, and one to resolve it against real component data
  and produce the finished schematic. Both come with a full manual
  page.

Version 0.64.0 (2026-09-11)
============================
* Automatic power-source handling is now complete: when a circuit
  has more than one power source, the most-used one is correctly
  preferred for direct rail attachment, and any other source is
  handled the same, general way any ordinary component would be --
  verified end to end with a real, two-source example circuit, on
  both the breadboard and schematic sides.
* Fixed two real, separate placement gaps found while finishing the
  above: a component's far connection point could, in rare cases,
  end up landing on exactly the same physical spot as a different
  component's own connection, undetected; and a component that
  needed to attach directly to a power rail could be left
  unplaced entirely, even when room was genuinely available further
  along the board. Both fixed at their real, underlying cause, not
  patched around -- and, as a welcome side effect, this also
  resolved several already-existing components that were silently
  going unplaced on two of this project's own standard, more
  complex test circuits.

Version 0.63.0 (2026-09-10)
============================
* The complete loop now works end to end: build instructions can be
  read back into a working circuit description, resolved against
  real component data (from KiCad's own libraries, or from Eagle
  format for parts that only ship that way), turned into a real
  KiCad schematic, and carried back through to build instructions
  again -- verified against a real, three-part example circuit with
  zero electrical-rule errors.
* New: automatic identification of a circuit's own power source
  (battery, USB, regulator output, etc.), so it gets placed and
  connected sensibly even when nothing else in the circuit happens
  to connect to it directly.
* A known, deliberately deferred item: prioritizing the most-used
  power source when a circuit has more than one is built but not
  yet enabled, since enabling it was found to expose a separate,
  pre-existing weakness in the placement search on one specific,
  complex circuit. Left off for this release rather than risk that
  regression; the underlying feature is ready to switch on once
  that separate issue is resolved.

Version 0.62.0 (2026-09-10)
============================
* Found and closed a genuine, project-wide gap: every one of this
  project's own eight standard circuits could produce an
  undetected electrical short under certain, valid layouts,
  because a component's second connection point was never checked
  against anything. Found by building a new feature that reads
  build instructions back into a circuit description, then
  confirmed across every existing example. Fixed at the actual
  root cause (the placement search itself now avoids these
  positions), not just detected after the fact -- confirmed clean
  on all eight circuits, with no side effects on any existing
  test.

Version 0.61.0 (2026-09-09)
============================
* Found and fixed three more performance problems on top of the
  two fixed in 0.60.0, all found the same way: attaching a live
  profiler to an actual, slow run rather than guessing. Confirmed
  this project's own largest real circuit is unaffected. A deeper,
  intermittent slowness in the automated test suite was
  investigated as far as this environment allows and left honestly
  open, with concrete next steps recorded.

Version 0.60.0 (2026-09-09)
============================
* Fixed two performance problems found directly from an
  independent live profile of an actual, slow run on a separate
  computer -- the most valuable single piece of information this
  investigation received. A gap in this project's own available
  tooling was found and corrected along the way.

Version 0.59.0 (2026-09-08)
============================
* Fixed the slowdown recorded but deliberately left open in the
  previous release. A separate, larger slowdown was found in a
  different, more delicate part of the code and deliberately left
  for a future, dedicated fix, along with an unresolved,
  intermittent slowness in this project's own verification process
  -- both recorded honestly rather than hidden. Also removed two
  unnecessary files from a contributed test circuit.

Version 0.58.0 (2026-09-08)
============================
* Fixed a real slowdown, previously found but deliberately left
  open, where a specific, internal lookup used by circuit layout
  searched the entire circuit from scratch every time it was asked a
  simple question. Applied the same fix everywhere else in this
  project's own code that had the identical problem. A separate,
  unrelated slowdown was found and documented along the way, though
  not yet fixed.

Version 0.57.0 (2026-09-08)
============================
* Fixed a crash that could occur when laying out a large, dense
  circuit with many small components, closing the one gap left open
  in the previous release. A separate, unrelated slowdown was found
  and documented, though not yet fixed.

Version 0.56.0 (2026-09-07)
============================
* Substantially sped up laying out and drawing large, real circuits
  -- roughly fourfold faster for one part of the process, and a
  drawing step that previously never finished in time for this
  project's own largest real test circuit now completes in about
  twenty seconds. A separate, real crash that can occur on circuits
  this large and dense was found and documented, though not yet
  fixed.

Version 0.55.0 (2026-09-06)
============================
* Fixed a real bug where, in an unusual but real case, the exact
  same circuit could be laid out slightly differently from one run
  to the next, for no meaningful reason. Placement is now
  consistent, run after run, given the same input.

Version 0.54.0 (2026-09-06)
============================
* Two new documents added to this project's own documentation set: a
  troubleshooting guide for when a real circuit doesn't lay out
  well, and a debugging guide for developers working on this
  project's own code, both grounded in real, worked examples rather
  than general advice.

Version 0.53.0 (2026-09-06)
============================
* Confirmed and proved that a previously reported, occasional crash
  under one specific, unusual configuration no longer happens, and
  added a permanent check to make sure it stays that way.

Version 0.52.0 (2026-09-06)
============================
* This project's own policy on component mounting style is now
  explicit and automatically checked: default component footprints
  are through-hole only, with surface-mount parts allowed only when
  a real, known breadboard adapter exists for that specific part.
* Investigated whether the layout engine ever tries reorienting an
  oversized component before giving up on placing it. Confirmed it
  does not, and confirmed there is currently no component type that
  would actually benefit from this, so no change was made -- the
  reasoning and the conditions that would change this are recorded
  for later.

Version 0.51.0 (2026-09-06)
============================
* Fixed a real bug reported by an external user of this project:
  resistors and diodes could be measured using the wrong physical
  size, causing them to sometimes be placed outside a board's own
  real limits. Corrected to use each part's own real, standing-up
  dimension, matching how these parts are actually built for use on
  a breadboard.
* It's now possible to find out exactly which components, and why,
  had to fall back to a less precise sizing estimate instead of
  using real, measured data -- useful for diagnosing an unexpected
  layout without guessing.
* Fixed a real bug where rendering a layout that hadn't been checked
  first could crash with an unhelpful internal error. This project's
  own renderer now checks the layout itself first and reports a
  clear, specific problem instead.
* Added the real circuit from the external report above to this
  project's own test circuits, and its own automatic checks.

Version 0.50.0 (2026-09-03)
============================
* This project's own documentation set has been audited for
  freshness and brought up to date. No code changed in this release.
* The concept document's own description of this project's goals now
  covers everything it currently does, including the build-guide
  generator and support for assemblies of several physical boards,
  and points to this project's own other documents for more detail.
* Several genuine inaccuracies were found and corrected in the
  library reference and workflow documents, each checked directly
  against the actual, current code rather than assumed. A few real,
  current command-line options that had no documentation at all now
  do, and an internal contradiction in one manual page (one part
  claiming a feature worked, another part of the same page saying it
  didn't) was found and resolved.
* One real, previously untracked limitation was added as a new,
  clearly scoped item to this project's own list of open work.

Version 0.49.0 (2026-09-03)
============================
* The project's own broad verification check has been substantially
  strengthened. Previously, checking whether a change had broken
  anything across this project's own full range of test circuits and
  board configurations required manually running a separate check by
  hand; this is now done automatically every time the project's own
  standard test suite runs, with no extra steps needed.
* Found and fixed a real bug while building this: drawing several
  circuits back-to-back within the same process could cause a later
  circuit to be incorrectly flagged as overlapping with an earlier,
  completely unrelated one. This has been corrected.
* Confirmed the new check genuinely works by testing it against the
  actual bug it was built to catch, not just confirming it runs
  cleanly.

Version 0.48.0 (2026-09-03)
============================
* Fixed a real, previously-unnoticed bug in assemblies of several
  boards: when a design has to fall back to a board's own edge
  connector as a last resort (no other rail configured), the
  fallback's own internal placement tracking used to be shared
  across every board, instead of kept separate per board. A board
  processed later could silently inherit an already-used-up count
  from an earlier one, causing its own connections to land in the
  wrong place without any warning or crash. This is now correctly
  isolated per board.
* Investigated whether an unrelated, already-known limitation could
  be improved using the same planning-ahead approach behind the
  previous release. It could not, without breaking other, previously
  working circuits -- this was tested directly and reverted rather
  than shipped, and the finding is recorded so the same approach
  isn't tried again without new information.
* A separate, unrelated, pre-existing, occasional crash was found on
  one specific circuit under an unusual configuration while testing
  the above. Confirmed unrelated to any of this release's own
  changes and left for a future look, with an exact way to reproduce
  it recorded for whoever takes it on.

Version 0.47.0 (2026-09-03)
============================
* Further improved board assignment for assemblies of several
  boards, building on the previous release: components are now
  planned as a whole before any of them are placed, rather than one
  at a time in processing order, letting a small group make use of
  room an earlier, larger group left over. Confirmed to genuinely
  reduce the number of boards needed in a case built to require this.
* A real, serious bug was found and fixed while verifying this
  change, before release: for an unusually large group of components
  that wouldn't fit on any single board regardless, an early version
  could cause unrelated components to end up on the exact same
  physical connection point. This has been corrected and confirmed
  fixed.

Version 0.46.0 (2026-09-02)
============================
* For assemblies of several boards, closely related larger
  components (chips, connectors, and similar) are now more likely to
  end up on the same board as each other, rather than being split
  apart simply because of the order they happened to be placed in.
  This completes the work started in the previous release, whose own
  fix addressed a related but smaller part of the same underlying
  question.
* Unlike the previous release's own fix, this one has been directly
  and repeatedly confirmed to work as intended on a real test case
  built specifically to exercise it.
* Two narrower, specific situations remain where this does not fully
  help, and are now clearly documented: a group of components large
  enough that it wouldn't fit on any single board regardless, and
  situations where an earlier placement decision would need to be
  reconsidered to make room for a later one. Neither is addressed by
  this release.

Version 0.45.0 (2026-09-02)
============================
* A small, verified correctness fix for assemblies of several
  boards: when a component has to move to a different board because
  its preferred one is full, the choice of which other board to try
  now correctly prefers one that already holds more of that
  component's own related connections, rather than trying boards in
  a fixed, arbitrary order.
* This is reported honestly as a partial result, not a complete
  solution: testing on a real, densely connected circuit found this
  specific fix did not measurably reduce the number of connections
  needed between boards, since most such connections in that circuit
  come from a different, larger part of the process not addressed
  here. That larger piece remains open and is now precisely
  described for future work, rather than left vague.

Version 0.44.0 (2026-09-02)
============================
* Build instructions can now be ordered by which specific connection
  point each component uses, so related parts -- a crystal and its
  supporting capacitor, for example -- are described together rather
  than scattered throughout the list. Available via the existing
  ordering option, alongside the previous choices.
* Confirmed this works correctly against a real microcontroller-
  based circuit specifically, since a naive version of this idea
  would fail exactly there: a microcontroller connects to almost
  everything, so a simpler grouping approach would collapse nearly
  every other component into one unhelpful group. This is avoided.

Version 0.43.0 (2026-09-02)
============================
* Fixed a confirmed bug where, in certain circuits, using a taller
  breadboard could paradoxically produce a worse result than a
  shorter one. Traced to a genuine interaction between two parts of
  the layout process and fixed with two complementary changes.
  Verified repeatedly, not on a single run, against both real cases
  that originally revealed this, with zero change to any other
  circuit's own result.
* A real misstep was found and corrected during this work, not
  shipped: an early version of the fix reserved too much space in
  one specific situation and broke a different, previously-working
  circuit. This was caught before release by comparing against a
  clean baseline.
* A narrower version of the same underlying issue remains for
  circuits with more unusual connection patterns, and is recorded
  honestly as a known, separate, smaller limitation rather than
  claimed as fully resolved.

Version 0.42.0 (2026-09-02)
============================
* Fixed a drawing bug affecting assemblies of several different
  breadboards: a component's second connection point could
  occasionally be positioned on the wrong physical board, or, in
  dense circuits, land on top of another component's own connection
  wire. Both are now handled correctly. No change to any existing,
  single-board circuit's own output.
* A narrower, related limitation has been identified and left open
  rather than worked around: under unusually dense, artificial
  conditions, a component's very first connection point can still
  occasionally end up too close to another one, since that position
  is chosen earlier in the process and can't be revisited later.
  This has been confirmed to only affect extreme, unrealistic cases,
  not the ordinary use this project is designed for -- confirmed by
  testing several genuine circuits against a real multi-board
  assembly repeatedly, not just once.

Version 0.41.0 (2026-09-01)
============================
* Fixed a bug that could cause an outright crash on very wide
  circuits: an internal limit on how much horizontal room a single
  breadboard section could use was based on an assumption that held
  for every circuit this project had designed itself, but turned out
  to be too small for a real circuit from KiCad's own official demo
  collection. This limit has been raised well beyond anything likely
  to be encountered in practice.
* A separate, unrelated limitation has been identified at this
  project's largest tested scale so far (over 1500 components): it
  currently takes too long to complete. This is a performance issue,
  not a correctness one, and has been recorded for future work
  rather than worked around.

Version 0.40.0 (2026-08-31)
============================
* Housekeeping release: no functional changes to the tools
  themselves, aside from removing three unused internal functions
  that had never actually been connected to anything (confirmed to
  have no effect on any output). The project's own internal planning
  document has been substantially cleaned up, removing a large
  amount of already-completed work that had accumulated there
  instead of being retired once finished.

Version 0.39.0 (2026-08-28)
============================
* Assemblies of several genuinely different breadboards can now be
  drawn and turned into build instructions, completing the layout
  support added in the previous release. Testing this thoroughly
  surfaced several real, pre-existing display bugs in the previously
  released same-shaped-boards feature -- most notably, components
  like integrated circuits, trimmers, USB-C connectors, and MOSFETs
  could render at the wrong vertical position on any board after the
  first. These are all fixed now.
* Fixed a genuine placement bug found while testing this: when a
  component needed to be moved to make room, it could be validated
  against the wrong board's own size, occasionally causing two
  different components to be placed in the exact same spot.
* A narrow, specific remaining limitation has been identified and
  documented precisely: very dense circuits placed extremely close
  to a boundary between two different boards can still occasionally
  have a connection land in the wrong spot. This has been confirmed
  to only affect that specific situation, not circuits in general.
  Build-instruction generation now reports this honestly rather than
  failing outright when it happens.

Version 0.38.0 (2026-08-27)
============================
* The layout engine can now genuinely place a circuit across an
  assembly of several different breadboards, building on the
  position calculations added in the previous release. A circuit
  that's too tall for one small board, for example, can now actually
  spread onto a taller board placed alongside it, rather than simply
  failing.
* A known limitation, found and documented while confirming this
  works: a component can still occasionally end up on a board that's
  tall enough for its own body but not quite tall enough for its
  power or ground connection, since which board a component's main
  body goes on doesn't yet take board height into account, only
  width. This is recorded clearly as a next step, not silently left
  unhandled -- affected circuits will report this honestly rather
  than producing an incorrect result.
* This release covers the layout engine only. Drawing the result and
  generating build instructions for an assembly of different boards
  are not yet updated to match, and are planned as a following step.

Version 0.37.0 (2026-08-27)
============================
* Confirmed that using multiple sectors on a single virtual
  breadboard cannot work around a component or wire needing more
  rows than that breadboard has, no matter how many sectors are
  used. Every sector on one breadboard always has the same row
  count, so this kind of problem genuinely needs a different,
  taller breadboard -- not more of the same one.
* Laid the groundwork for assemblies built from several genuinely
  different breadboards -- for example, a small one alongside a
  larger, taller one -- rather than several identical ones. This
  release adds the underlying position calculations only; using
  them to actually decide where components go and how the result is
  drawn is planned as a following step.

Version 0.36.0 (2026-08-27)
============================
* Changed: the default breadboard now has 5 rows on each side of the
  center divider instead of 10, matching a real, physical breadboard
  rather than an unverified assumption inherited from early in this
  project. A taller board is still available any time it's needed,
  by giving an explicit configuration file -- it's just no longer
  assumed by default.
* As a direct, expected consequence of the above, every circuit
  bundled with this project -- including its own simple example
  circuits -- now needs an explicit, taller board configuration to
  lay out at all, since the smaller, more realistic default
  genuinely isn't big enough for them. This is reported cleanly, not
  as a crash, and every circuit still works correctly once given a
  suitable configuration.
* Fixed two bugs found while confirming the change above, both
  present since well before this release: two internal checks (one
  in the main rendering path, one in the build-instructions tool)
  were silently using a fixed row count instead of the row count
  from whatever board configuration was actually in use. This had
  gone unnoticed because the two numbers used to always match by
  coincidence.

Version 0.35.0 (2026-08-27)
============================
* The second, alternate demo-circuit source (the system package)
  has now been tested for the first time. Most of its circuits turn
  out to be the same designs already available from the primary
  source, just in an older file format; testing focused on the
  handful that are genuinely unique to it.
* Fixed a documentation inaccuracy: the age difference between the
  two demo sources was described as if it were a permanent
  characteristic of one of the fetch methods. It's actually just a
  reflection of how old this project's own development environment
  is -- on a more up-to-date system, both sources would match.
* While testing, a genuine, reproducible layout problem was found
  and confirmed on two unrelated circuits: for certain designs, a
  taller virtual breadboard consistently fails to lay out correctly
  where a moderately shorter one consistently succeeds -- the
  opposite of what would normally be expected. This has been
  recorded precisely for future investigation rather than fixed in
  this release, since confirming it was genuine (rather than one of
  a few already-known, harmless sources of run-to-run variation)
  took the available time on its own.

Version 0.34.0 (2026-08-27)
============================
* The KiCad demo circuits fetched by fetch-kicad-demos are now kept
  in a persistent, on-disk cache instead of being downloaded fresh
  every time. Re-running the script simply reports what's already
  available; a new --update flag refreshes it, and a new --clean
  flag removes it, on request only. This cache lives outside the
  project and is never touched by ordinary cleanup.
* fetch-kicad-demos can now also pull its demo circuits from the
  "kicad-demos" system package, as a second, independent source with
  its own set of circuits (drawn from an older KiCad release, so it
  includes some older example projects no longer distributed
  upstream). This works without any special privileges.
* Four circuits that previously failed to lay out have been
  investigated in depth. Two now resolve automatically. The other
  two need a taller board rather than more of the same board, which
  turned out to already be the intended, documented behavior rather
  than a gap to close -- confirmed by re-checking the existing
  design before changing anything. Testing has continued through two
  further tiers of circuit complexity, turning up two more cases of
  the same, already-understood issue, plus one open question flagged
  for future investigation rather than left unmentioned.

Version 0.33.0 (2026-08-26)
============================
* New: fetch-kicad-demos, a script that fetches KiCad's own official
  demo/example circuits for use as a wider test surface. These stay
  external to the project rather than being copied in, and can be
  refreshed at any time by re-running the script.
* An empirical complexity table has been built across all 33 real
  demo circuits this brings in, ranging from 3 to over 1500
  components, providing a natural, bottom-up path for further
  testing. An initial pass on the smallest of these has already gone
  cleanly; a few of the medium-sized ones have already turned up
  genuine placement issues worth investigating further.
* Fixed: the release-packaging script's own safety check (which
  confirms every shipped script is still marked executable before
  building an archive) had fallen out of sync with the recent script
  renaming and was silently skipping every renamed file. It now
  checks the correct, current set.

Version 0.32.0 (2026-08-26)
============================
* Changed: every executable script has been renamed, dropping its
  file extension and gaining a "pp" prefix specific to this project
  (render.py is now pprender, auto_layout.py is now ppauto_layout,
  and so on for the rest). This avoids clashing with other, unrelated
  tools that share common names like "render" on a typical system.
  Files that are used only as internal libraries, and never invoked
  directly, keep their original names and are unaffected.
* Fixed: the documentation index link at the top of each manual
  page's HTML rendering pointed one directory level too high and did
  not work. It now correctly returns to the documentation index.
* Fixed: the file-format manual page for breadboard configuration
  files was missing from the documentation index; it and three other
  manual pages that had the same problem are now linked.
* The breadboard configuration file format's own manual page now
  documents multi-board assemblies in full, including a complete,
  working example of two boards with genuinely different layouts
  combined into one project.

Version 0.31.0 (2026-08-26)
============================
* New: build_instructions.py, a new tool converting a breadboard
  layout into a textual, step-by-step build guide -- the first
  script in this project that produces prose instead of a picture.
  Given a schematic, it walks through the same auto-layout pipeline
  render.py uses and produces an ordered list of build steps: which
  component goes where, in which hole, with which value and type,
  and which wires connect what -- written to be read while building,
  not just looked at while designing.
* Component descriptions include the part's type and value, not just
  its reference designator, and can optionally link to further
  reading: a Wikipedia article for common parts like resistors and
  capacitors, or a datasheet search for anything more specific.
* Steps default to an order based on physical position on the board,
  chosen because it noticeably reduces how much a builder's hands
  have to jump around while working -- confirmed on a real, dense
  circuit before being made the default. A simpler, reference-order
  alternative is also available.
* Output can be plain text, Markdown, HTML, or Org-mode, and a
  simpler, child-friendly phrasing option is available alongside the
  default, more technical wording.

Version 0.30.1 (2026-08-26)
============================
* Fixed: a component's actual power or ground wire could still land
  at the wrong vertical position on any board after the first, in a
  multi-board split -- the previous release fixed this for the board
  frames and rail bridges themselves, but missed the one function
  that draws each individual component's own connection to its rail.
  Every column needing power or ground now correctly uses the rail
  belonging to its own sector and board.

Version 0.30.0 (2026-08-25)
============================
* Fixed: components placed on any board after the first, in a
  multi-board split, could appear vertically misaligned against that
  board's own frame. The rendering code computing component
  positions had not been updated to account for the gap between
  boards, even though the board frames themselves already were.
* New: real power/ground rail continuity, now correctly represented
  whenever a single net's components land on different rails --
  whether across sectors on one board, or across separate boards.
  This closes a gap that predates multi-board support entirely: a
  net split across two rails within a single board was previously
  left electrically incomplete in the render, with no wire shown
  connecting them. Rail connections are now drawn as genuine wires
  between real, physical holes, matching how every other connection
  in a render is drawn -- not a decorative line. Where a connection
  would need to cross a board boundary, a labeled off-board connector
  is drawn at each end instead, since no physical wire can span two
  separate boards.
* Changed: in a multi-board render, each board now gets its own
  legend, positioned to its right rather than underneath -- avoiding
  a design where the gap between boards would need to grow or shrink
  based on how many components happen to be on each one. A
  single-board render's legend is unaffected.

Version 0.29.0 (2026-08-25)
============================
* New: the geometry foundation for multi-board assemblies with TRUE
  splitting -- a circuit's own components genuinely spread across
  separate physical boards once a configurable per-board sector
  limit is exceeded (e.g. no more than 4 sectors on one board), each
  one meant to be rendered with a real visual boundary and inter-
  board wire connectors going forward. This release lays the
  groundwork only: the geometry needed to correctly position
  multiple, non-overlapping boards is built and thoroughly verified,
  but the actual rendering (visual boundaries, a legend, and the
  wire connectors themselves) is deliberately left for a dedicated
  next step, given the risk of rushing a substantial change to
  central rendering code.
* No behavior change for existing, single-board use -- every new
  function reduces to today's exact, existing output when the new
  per-board limit isn't set, confirmed by a full regression sweep
  showing zero difference from the previous release.

Version 0.28.0 (2026-08-25)
============================
* New: MultiboardConfig, a real, deliberately narrow first step
  toward describing an assembly built from multiple separate
  physical boards, as raised directly. This defines the file format
  and a tested parser/writer only -- a multi-board file lists
  existing, single-board config files by path, reusing the proven
  single-board parser unchanged. Placement and rendering do not yet
  understand multiple boards; that remains a real, separate,
  larger undertaking, deliberately not attempted here.
* Fixed: breadboard_config.py itself had no automated test at all
  before this release, despite extensive manual verification across
  many sessions -- test_breadboard_config.py now covers both the
  long-standing single-board functions and the new multi-board ones,
  and runs as part of make check going forward.

Version 0.27.0 (2026-08-24)
============================
* New: breadboard_config(5), a manual page for the breadboard config
  file format itself -- every section and key, its own meaning and
  default, a worked example, and the physical rail-sector-rail model
  the format describes. Closes a direct request from several
  sessions ago, deferred until the format itself stopped changing.
* Fixed: the existing breadboard_config(1) page was found to be
  significantly out of date while writing the new one -- it still
  described a schema that had since been corrected, and claimed no
  other program used a config file when two now do throughout. Both
  are now accurate, and the file-format details live in one place
  instead of two.
* Fixed: two related, stale code comments in breadboard_config.py
  that still described the module as a standalone, not-yet-wired-in
  step, predating the extensive integration work since.

Version 0.26.0 (2026-08-24)
============================
* Fixed: rp2040-basic-m1's own sector-count bias, the circuit that
  started this whole multi-session investigation, is genuinely
  resolved -- along with example_circuit1's own long-standing "Z"
  net issue. Both circuits now fit cleanly on a SINGLE sector
  (previously 4-5 sectors for rp2040-basic-m1, and an outright
  failure for example_circuit1). This closes two real, separate
  problems together: a placement mechanism now correctly predicts,
  before committing to a position, whether a neighboring adjacency
  rule will later push a component deeper than expected -- in both
  directions, not just one -- and separately, direct wires between
  components are now given the room they'll need in advance, rather
  than discovering too late that none is left.
* Verified extensively given the history of this specific area: the
  full 35-combination stress test shows zero regressions -- every
  real difference from the previous release is a genuine
  improvement. Both resolved circuits' own final renders were
  visually inspected and confirmed clean.

Version 0.25.2 (2026-08-24)
============================
* Documented: solving the ping-pong problem together with the
  room-visibility gap, as directly instructed. A precise wire-margin
  mechanism was designed and confirmed correct on its own terms, but
  testing revealed a third, previously-unknown factor -- a separate
  mechanism's own genuine reason to push a component deep into its
  column, unrelated to wire margin -- that defeats it too. This is
  now understood as a genuine three-way interaction rather than a
  two-way one. Reverted rather than ship a regression; no functional
  code change from 0.25.1. Two concrete directions are recorded for
  a future attempt.

Version 0.25.1 (2026-08-22)
============================
* Documented: designed and implemented a real solution to the
  sector-count bias, as directly requested. A genuinely effective
  mechanism was found and verified (relief_history, structurally
  preventing the per-ref oscillation that previously defeated a
  wider room search), resolving rp2040-basic-m1 at a single sector
  instead of four or five. But the full regression suite caught a
  different, real problem this same fix exposed -- a component
  needing two separate direct wires from the same column was left
  with only enough spare room for one, a gap in a different,
  downstream part of the layout engine. Two further attempts at
  fixing that specific problem were both insufficient. Reverted
  rather than ship a regression; no functional code change from
  0.25.0. A precise, two-problem account is recorded for a future
  attempt that addresses both together.

Version 0.25.0 (2026-08-22)
============================
* Fixed: to_rail()'s own final fallback tier (used when no rail is
  configured at all) is now sector-aware -- a real, overlooked
  sibling of a bug already fixed in a different tier of the same
  function. Traced from an apparent "unpowered sectors" appearance
  in a rendered rp2040-basic-m1, most of which turned out to be a
  test-configuration artifact rather than a real bug, but this one
  piece was genuine.
* Investigated further, not yet resolved: a real, confirmed bias in
  rp2040-basic-m1's own sector-count resolution, spreading across
  more sectors than necessary while leaving most of them mostly
  empty. Two careful attempts at a fix were both caught by direct
  testing and reverted rather than shipped -- one left real
  components permanently stuck overflowing, the other re-introduced
  a ping-pong the existing cycle detector doesn't catch. Both real
  failure modes are precisely recorded for a future, more careful
  attempt.

Version 0.24.0 (2026-08-22)
============================
* Fixed: a real, deeper bug found while re-verifying a precisely-
  scoped item from the previous release -- run_declutter()'s own
  "push aside" search could wrap a component backward across a
  sector boundary, landing it at an extreme, out-of-bounds column
  (confirmed: one real component landed at local column 1000 on a
  board configured for 65). This produced a visibly wrong, massively
  oversized canvas for rp2040-basic-m1's own real render. Fixed with
  a real, targeted boundary check. rp2040-basic-m1 now renders at a
  sensible size and, on a realistic board shape, resolves with one
  fewer sector than before -- a genuinely more efficient placement.
* Fixed: to_rail() and jumper() now both register their own real
  landing spot, closing the original far-leg hole-collision finding
  directly -- confirmed to change nothing about already-verified
  render output, since this only affects collision-avoidance
  bookkeeping.
* Verified extensively given the recent history of regressions in
  this exact area: the full 35-combination stress test run before
  and after both fixes showed zero difference in any already-
  verified placement outcome.

Version 0.23.0 (2026-08-22)
============================
* Fixed: a foundational structural correction to the multi-sector
  breadboard geometry model. A real, N-sector board's own real
  vertical structure is rail, sector, rail, sector, ..., rail -- N+1
  real rails, each one SHARED between the two sectors it sits
  between, not a separate rail pair duplicated per sector. The
  entire geometry model, both real config files, and every consuming
  function were revised accordingly. Verified extensively given the
  foundational stakes: a 35-combination stress test run before and
  after showed zero difference in any already-verified placement
  outcome, and a real multi-sector render was visually inspected to
  confirm exactly the right number of rails, each a single, clean
  pair.
* New: an optional right/vertical rail (rail_right), alongside the
  existing left rail -- schema support only; its own real connection
  logic is deliberately deferred, since its position depends on the
  board's own final width in a way the left rail's fixed offset
  doesn't.
* New: two items recorded in FutureResearch.org for future work --
  assemblies built from multiple separate physical boards, and
  documenting the breadboard configuration file format (deferred
  until the format stabilizes, per direct request).

Version 0.22.0 (2026-08-21)
============================
* Fixed: rp2040-basic-m1's own sector-preference question, the last
  real piece of its own multi-session capacity investigation.
  relieve_overflow() now actively prefers a genuinely less-crowded
  sector when relocating an overflowing component, rather than
  always searching near wherever it already is -- protected by a
  now-complete cycle-detection safety net that guarantees this can
  only ever help. This resolves TWO previously-documented "genuinely
  unfixable by any sector count" cases: example_circuit1's own real
  "Z" net overflow, and rp2040-basic-m1 itself, which resolves for
  the first time ever (at 5 boards). Both now render cleanly through
  the plain CLI with no explicit board configuration needed.
* Found and precisely scoped (not fixed): a real, narrow rendering
  gap specific to rp2040-basic-m1's own dense topology -- to_rail()
  never registers its own landing spot when a component's far pin
  reaches a rail directly, so two nearby components reaching for the
  same rail can land at the exact same pixel. Confirmed this doesn't
  affect any other real circuit; a concrete fix direction is
  recorded for whenever it's picked up.

Version 0.21.0 (2026-08-21)
============================
* Fixed: the shared relocate-on-overflow ping-pong (a real bug
  causing some components to be relocated back and forth between the
  same two columns dozens of times before an iteration cap simply
  stopped the loop) is genuinely fixed. A sixth attempt at this
  mechanism uses exact-state cycle detection -- a real, hashable
  fingerprint of the full placement state, checked for an identical
  repeat -- rather than a heuristic that could mistake genuine
  progress for a stall, the flaw that caused two earlier attempts
  this same day to be reverted. Verified with the most rigorous
  testing this item has had: a 35-combination stress test (every
  real circuit against 5 real board shapes) run both with and
  without the fix and diffed with zero difference, plus a direct,
  side-by-side confirmation that the fix changes nothing about the
  real outcome for the circuit that first exposed the bug, only how
  efficiently and provably it's reached.
* rp2040-basic-m1's own deeper capacity ceiling (a separate, harder
  question about preferring a less-crowded sector) remains open, as
  expected -- this release closes its own real prerequisite.

Version 0.20.0 (2026-08-21)
============================
* New: rail nets are now checked for a real, genuine power source.
  render.py prints a real, non-blocking advisory when a rail net
  (classified purely by member count) has no power_out pin anywhere
  and no power_in pin either -- a real, useful signal that already
  catches the same underlying issue as the charlieplex/rail-
  classification fix, from a different angle. Honestly flags -- and
  documents -- a real limitation: a generic connector symbol standing
  in for an actual power source (common in hobbyist circuits) looks
  the same to this check, so a flagged net is a signal worth a look,
  not proof of a problem.
* Investigated further: rp2040-basic-m1's own row-depth ceiling. A
  fifth real attempt genuinely eliminated the shared relocate-on-
  overflow ping-pong (confirmed: relocation counts dropped from
  roughly 30 to 3) but caused a second real, confirmed regression on
  two previously-clean circuits, caught by the full regression sweep
  and reverted before shipping -- no functional change to this
  mechanism from 0.19.1. The precise reason (a "stop at first non-
  improvement" rule can't distinguish a genuine ping-pong from a real
  plateau) is recorded for whoever picks this up next.

Version 0.19.1 (2026-08-21)
============================
* Documented: rp2040-basic-m1's own row-depth ceiling investigated
  further -- two real attempts, each yielding genuine new
  understanding. The first (a targeted cursor jump) was confirmed
  harmless but didn't help. The second (a dedicated, forward-only,
  always-fresh search) was a real improvement on rp2040-basic-m1
  alone, but caused a real, confirmed regression on knight-roller --
  caught by the full regression sweep and reverted before shipping.
  No functional code change from 0.19.0. A real, separate, deeper
  bug found while diagnosing the regression (the shared relocate-on-
  overflow code can ping-pong between two columns before accepting a
  still-overflowing result) is recorded as the most promising real
  next direction.

Version 0.19.0 (2026-08-21)
============================
* Improved: rp2040-basic-m1's own row-depth competition -- the rail-
  attachment fallback's own room search now advances to a fresh
  starting column after each attachment and uses each component's
  own real, estimated size upfront (fixing a real bug where same-net
  components were funneled into one column before their real size
  was ever checked). A real, measurable improvement, though the
  circuit's own deeper capacity ceiling remains -- its actual root
  cause is now traced precisely and recorded for future work.
* New: real CLI plumbing for the breadboard-configuration resolution
  strategy -- render.py gains --config, --use-computed, and
  --require-config flags, wiring together every already-tested piece
  of the resolution algorithm. A circuit that doesn't fit the
  default board now automatically renders via the plain CLI alone,
  no separate script needed. A real crash bug (an unhandled
  exception from an exhausted search) found and fixed along the way.
* Fixed: the assembly's own left/vertical rail's real connection
  priority, corrected per direct review -- an initial "nearest rail"
  implementation (picking whichever of the bottom or left rail was
  geometrically closer) was backwards. The left rail's real role for
  a direct component connection is a genuine last resort (no room on
  the horizontal rails, or a separate power source), never a
  proximity comparison -- corrected accordingly.
* New: two items recorded in FutureResearch.org for future work --
  verifying that rail nets trace back to a genuine power source, and
  a real feature idea to convert a rendered breadboard diagram into
  a textual, step-by-step build instruction list.

Version 0.18.0 (2026-08-21)
============================
* New: the charlieplex/rail-classification gap is closed -- a
  passive whose entire connectivity routes through nets classified
  as rails can now attach directly to one, the same real option
  anchors already had. Verified against the real, originally-
  diagnosed case: TestSchemes' own knight-roller project (D2/D4/D6/
  D7, unplaced since this project's own 2026-08-19 diagnosis of this
  exact gap) now places correctly and renders correctly.
* Fixed: a real, confirmed bug in to_rail()'s own final fallback
  tier -- was not sector-aware, silently drawing a rail connection
  to the wrong sector's own position on a genuinely multi-sector
  board with no rail configured anywhere. Found by looking at an
  actual rendered image.
* New: a real, honestly-reported capacity finding in
  rp2040-basic-m1 -- the charlieplex fix's own success places 8 more
  real components there, but the circuit is now crowded enough that
  compute_optimal_config() cannot resolve it even at 10 boards;
  confirmed this is genuine row-depth competition, not a column-
  width limit. Recorded as a real, separate, deferred item, not
  fixed under time pressure.
* Improved: "Real breadboard configuration" finalized --
  rp2040-basic-m1's own original row-capacity item closed (resolved
  by compute_optimal_config(), not a separate fix), stale references
  to compute_optimal_config() as unbuilt corrected throughout.

Version 0.17.0 (2026-08-20)
============================
* Fixed: a real, confirmed bug in the assembly's own left rail
  connection -- multiple components wiring to it landed at the exact
  same hole, since every anchor in this project's own placement
  model shares one outer row. A new tracker now advances each
  successive connection to a genuinely distinct position.
* New: the assembly's own left rail now also gets its real, primary
  role -- common power distribution to each sector's own local rail,
  drawn as a real, structural board-level connection (four short
  bridges per sector: top+/top-/bottom+/bottom-), not something tied
  to specific components. Direct component-to-left-rail wiring
  (added earlier this same day) remains for the real, separate case
  of an additional power domain a sector's own local rail doesn't
  already provide.

Version 0.16.0 (2026-08-20)
============================
* New: to_rail() can now genuinely connect a component to the
  assembly's own left rail, when neither a sector-local rail nor the
  assembly's bottom rail is available. Reuses this project's own
  existing jumper() curve-and-collision-avoidance machinery, since a
  connection reaching the board's own side edge is far more likely
  to cross something than a short, local, vertical one. Verified
  both numerically and visually. This closes the rail-connection
  priority for all three real rail types this project's own boards
  can have; only a fully general "nearest real rail" strategy
  (comparing real distances across every option, rather than a fixed
  priority order) remains open in FutureResearch.org.

Version 0.15.0 (2026-08-20)
============================
* New: compute_optimal_config(), the last real piece of the
  breadboard-configuration resolution strategy -- given a real
  circuit and one real board's own shape, automatically finds how
  many of that board are genuinely needed, the same escalating-
  retry-ladder discipline already proven on the KiCad side. Verified
  against this project's own real circuits, including a genuinely
  hard one (rp2040-basic-m1, resolving at 2 boards) and a genuinely
  informative failure (example_circuit1, correctly reporting that no
  number of additional boards of the same shape can fix its own
  real, single-sector row-capacity overflow). This closes the last
  built piece of the resolution strategy; only the left rail's own
  electrical connection and a general "nearest rail" strategy remain
  open in FutureResearch.org.

Version 0.14.0 (2026-08-20)
============================
* New: to_rail() now has a real, tiered fallback -- a component in a
  sector with no local rail of its own can now genuinely connect to
  the assembly's own bottom rail (a real, simple vertical line, not
  yet a routed/collision-aware wire), instead of silently falling
  back to the single, default rail regardless of the real board
  described. Verified both numerically and visually.
* Fixed: row_letter() had its own bare, hardcoded ROWS_PER_HALF
  dependency (a real, distinct gap from phase 2's own earlier work,
  since this function uses neither col_x()/row_y()/TRENCH_Y) --
  crashed for a genuinely different real sector depth. Now takes an
  optional, real rows_per_half.

Version 0.13.0 (2026-08-20)
============================
* New: the assembly-level left and bottom rails (present on both real
  boards) are now genuinely drawn -- real +/- lines
  with real hole grouping, spanning the full assembly. Implemented
  without disturbing a single existing position: the canvas grows
  (a new, negative SVG viewBox origin, only when a left rail is
  configured) rather than shifting the coordinate system every
  existing render depends on. Verified both numerically (byte-
  identical output for every existing config) and visually (a real
  multi-sector render with both rails present, inspected as an
  image). Neither rail carries an electrical connection yet -- that
  remains open, tracked in FutureResearch.org.

Version 0.12.0 (2026-08-20)
============================
* Improved: geometry integration, phase 2 (render.py's own drawing
  side) is now fully closed, not just the exercised core. The four
  remaining shape functions (trimmer_straddle, usb_c, mosfet, bus --
  confirmed to have no real caller in render.py today) are now
  sector-aware, verified in isolation against known-correct pixel
  values. The cross-half rail-bridging path and the extra_notes path
  are also sector-aware, and both were genuinely exercised for the
  first time to confirm they work, not just edited and trusted.
* New: the assembly-level left/bottom rails (present on both real
  boards) are scoped as a real, distinct next
  feature in FutureResearch.org -- drawing them needs real canvas-
  coordinate-system changes, a genuinely different, larger piece of
  work than the mechanical per-function conversions that closed
  everything else in this release.

Version 0.11.0 (2026-08-20)
============================
* New: render.py's own drawing side now genuinely renders a
  multi-sector breadboard -- real trenches, rails, and dot grids per
  sector, correct canvas sizing for the whole assembly, and correct
  cross-sector jumper wires when a circuit's own components spill
  into more than one sector. Verified both numerically (the real
  generated SVG's own coordinates checked against this project's own
  existing constants) and visually (real multi-sector renders,
  including genuine anchor spillover, inspected as images). This
  closes the placement-and-rendering pair that started with 0.10.0's
  own auto_layout.py work; a real, bounded gap remains for four
  less-common shape functions and the assembly-level left/bottom
  rails' own drawing, neither exercised by any of this project's own
  real test circuits yet -- stated precisely in FutureResearch.org.
* Fixed: two more real geometry-formula errors, found the same way
  as 0.10.0's own wire_row() bug -- by checking against a known-
  correct value before trusting a derivation, not by inspection
  alone.

Version 0.10.0 (2026-08-20)
============================
* New: auto_layout.py's own placement engine now genuinely accepts a
  real breadboard_config.BoardConfig -- a real per-sector column
  bound, sector-spilling when the starting sector runs out of room,
  and every row-assignment site now uses the config's own real
  rows_per_half. Sector-aware anchor placement, confirmed necessary
  (not just thorough) after finding TestSchemes' own rp2040-basic-m1
  already needs it for anchors alone. This is the placement HALF of
  full multi-sector support; render.py/breadboard_lib.py don't yet
  consume a board config for actual drawing -- precisely scoped, not
  yet implemented, in FutureResearch.org.
* Fixed: a real, silent connectivity bug, self-introduced the same
  day as its own root cause (a wire_row() "room check" that
  relocated a bridging wire to an unrelated column, disconnecting it
  from the real component it existed to connect). Found only by
  testing a genuinely different rows_per_half for the first time;
  confirmed unrelated to sectors before reverting. Restores an
  honest bounds-check failure over a silent, incorrect connectivity
  pass -- both example circuits' own ROWS_PER_HALF overflow findings
  from earlier releases are the real, disclosed state again, not a
  regression.

Version 0.9.0 (2026-08-19)
============================
* Improved: breadboard_config.py's own rail-grouping estimate
  replaced with a real, physically-grounded formula (real observed
  margins and inter-group gaps), superseding the earlier, weaker
  curve fit. The bottom rail on both real worked
  examples now carries its own confirmed grouping too, matching the
  left rail and each sector's own local rail exactly.
* New: kicad_layout.py's own section in LibraryReference.org, the
  third complete library reference (after netlist.py and
  footprint.py).

Version 0.8.0 (2026-08-19)
============================
* Improved: breadboard_config.py's own two real worked examples
  gained a real, confirmed detail -- a sector's own local rail
  shares the same hole-grouping as the assembly's own left rail (10
  groups of 4 holes) -- plus a new, explicitly-hypothesized formula
  (estimate_rail_groups()) relating a rail's own group count to its
  sector's own column count, offered as a real starting point rather
  than a confirmed standard. Config files now carry a real $Id$
  header line.
* New: footprint.py's own section in LibraryReference.org, the
  second complete library reference (after netlist.py).
* Fixed: Workflow.org now mentions breadboard_config.py's own real,
  current scope -- the file format and lookup logic exist and are
  tested, but this project's own actual placement/rendering still
  addresses a single, fixed board shape; that gap wasn't
  documented until now.

Version 0.7.0 (2026-08-19)
============================
* New: LibraryReference.org, a single reference document for this
  project's own shared libraries (netlist.py, auto_layout.py,
  kicad_layout.py, footprint.py, breadboard_lib.py), deliberately
  kept separate from KicadGen.org (a genuinely different kind of
  reference -- a language's own syntax vs. a data model/algorithm/
  orchestration). netlist.py's own section is complete; the rest are
  honest, explicit stubs, not yet written.
* Improved: breadboard_config.py's own two real worked examples
  corrected with real measurements (5 rows x 65 columns per sector;
  the power/ground rails grouped 10 groups of 4 holes), and a real,
  tested config-file lookup order implemented
  (resolve_config_path()): an explicit path, then
  $PACKPAY_BREADBOARD_CONFIG, then a config file next to the
  schematic being processed, then the current directory.

Version 0.6.0 (2026-08-19)
============================
* New: breadboard_config.py, a real Unix-style INI configuration
  format for describing a target breadboard's own real assembly --
  sector count, per-sector geometry, and rail presence/continuity
  (both an assembly-level left rail and a bottom rail, matching real
  boards commonly built from multiple standard units mounted
  together). Implemented and round-trip tested, including two real
  worked examples from physical boards
  (breadboard1.conf, breadboard2.conf). This is the file-format
  layer only: it does not yet feed into this project's own actual
  placement/rendering geometry, which still uses a single, fixed
  board shape -- tracked as real, separate follow-up work in
  FutureResearch.org, along with the full resolution strategy
  (explicit config, default file, computed fallback) formalized
  there with concrete flag names but not yet implemented.

Version 0.5.0 (2026-08-19)
============================
* Documentation policy corrected: a script taking no options is
  still real, workflow-relevant tooling and belongs documented.
  example_circuit1.py, example_circuit2.py, and render_footprints.py
  now have real man(1) pages -- this project's own seventh, eighth,
  and ninth scripts to reach that bar, each with an honest OPTIONS
  section (--version/--help, and for render_footprints.py a real
  -o/--output and --quiet too) rather than left out for a reason
  that didn't actually hold up.
* Design direction added for the charlieplex/rails open item: a
  passive can attach directly to a power/ground rail, the same real
  option this project's own anchors already have, rather than
  requiring an entirely separate route through ordinary nets --
  matching how a real breadboard build under space pressure already
  works. Not yet implemented; recorded in FutureResearch.org for
  whenever this item is next picked up.

Version 0.4.0 (2026-08-19)
============================
* New: auto_layout.py and visualize.py brought up to a real
  command-line interface and given real man(1) pages -- this
  project's own fifth and sixth scripts to reach that bar. Every
  remaining script's own real status accounted for and the item
  closed: some are pure libraries with no natural entry point to
  upgrade (real, separate design work), others are fixed-content
  demos or explicitly internal harnesses with no real option to
  document.
* Fixed: a passive can now attach through another already-placed
  passive's own FAR pin during breadboard placement, not just its
  near one -- closing this project's own first open research item.
  Fixes a real, previously-unplaced case (TestSchemes' own knight-
  roller project), plus an unplanned bonus: example_circuit1.py's
  own C10/L10, unplaced since this project's creation, now place
  correctly.
* Fixed: a real, related gap this same fix exposed -- extra_links
  wire placement (wire_row()) had no room check, the one row-
  assignment site the 0.1.0 fix hadn't yet reached.
* Investigated and documented, not yet implemented: two further,
  genuinely separate findings surfaced while verifying the far-leg
  fix -- a member-count heuristic misclassifying a charlieplex
  matrix's own shared drive lines as power/ground rails, and a real
  row-capacity limit on this project's own largest test circuit (35
  components) once more of its own components place correctly.
  Both honestly reported (not crashes, not silent wrongness), both
  recorded in FutureResearch.org for whoever picks them up next.

Version 0.3.0 (2026-08-18)
============================
* New: test_netlist.py brought up to a real command-line interface
  (--kicad-cli/--version/--help/--debug/--quiet) and given a real
  man(1) page -- this project's own fourth script to reach that bar
  (after netlist.py, render.py, and footprint.py).
* Fixed: a real groff warning ("cannot adjust line") on footprint.1;
  all four of this project's own man pages now convert with zero
  warnings.
* Documentation: Workflow.org's own "Purpose of this document"
  section rewritten to describe what the document actually is,
  rather than the reasoning behind its creation (which belongs in,
  and is already recorded in, ResearchJournal.org).

Version 0.2.0 (2026-08-18)
============================
* New: footprint.py brought up to a real command-line interface
  (--version/--help/--debug/--quiet) and given a real man(1) page --
  this project's own third script to reach that bar (after
  netlist.py and render.py, both 0.1.0), extending the same, now
  three-times-verified pattern.
* New: Workflow.org, a real, previously-missing document walking
  through the actual pipeline -- from a real netlist to a placed
  diagram, and from an imported schematic (as in TestSchemes/) back
  to a newly laid-out one ("the loop") -- every command in it
  actually run and verified, not described from memory.
* Fixed: KicadGen.html was being generated but never linked from
  Index.html; a new "Reference" section links it now.
* Fixed: auto_layout.py's and visualize.py's own demo entry points
  still defaulted to a stale, dudhya-specific schematic path left
  over from the 2026-08-14 extraction.

Version 0.1.0 (2026-08-18)
============================
* Fixed: auto_layout.py's own row-assignment now checks available
  room before stacking components in a column (the 0.0.0 release's
  own honestly-documented open item), instead of only detecting the
  resulting overflow after the fact. Verified against the real,
  originally-documented failure (real KiCad footprint data, not just
  a synthetic stress case), and against both example circuits'
  own full pipeline (0 ERC errors, all real checks passing).
* New: real KiCad-environment setup, exercised and confirmed fresh
  in a from-scratch sandbox, following DevelopmentStandard.org's own
  documented procedure exactly (including its own documented
  fallback for an exhausted api.github.com rate limit).
* Settled: how a consuming project depends on packpay -- the
  PACKPAY_DIR environment-variable approach is kept; no pip package.
* New: man2htmldoc wired into the real Automake build (`make
  man-html`, `make html`), with its own real bug found and fixed
  (groff mis-rendering non-ASCII characters without -Kutf8).
  netlist.py and render.py are packpay's own first two
  scripts brought up to a real command-line interface (--version/
  --help/--debug/--quiet) and given a real man(1) page each,
  establishing a genuine, reusable pattern for the remaining
  scripts (tracked in FutureResearch.org).
* New: TestSchemes/, five real, trimmed, third-party KiCad projects
  (Jeremy Cook's own designs) kept as real test material, evaluated
  and verified against packpay's own full pipeline -- including two
  genuinely hierarchical, multi-sheet designs, exercising real
  multi-sheet netlist merging for the first time.
* Fixed: four real build/tooling issues found by actually running
  this project's own build -- a false-positive Automake portability
  warning, the VERSION file's own SVN keyword shipped pre-expanded
  by mistake, `make maintainer-clean` leaving a stray configure~
  backup file behind, and Index.org's own "Manual pages" section
  rendering empty (root cause: never actually linked, not a broken
  build step).
* Investigated and documented, not yet implemented: a real,
  structural gap in the breadboard placement algorithm, found
  evaluating TestSchemes -- a passive's own far leg is never a valid
  attach point for another component during placement, since that
  leg's column is currently decided only at render time. Full
  mechanism and a real design sketch recorded in FutureResearch.org
  and ResearchJournal.org for whoever picks it up next.

Version 0.0.0 (2026-08-14)
============================
* First delivery: packpay created by surgical extraction from the
  dudhya project. A netlist-driven schematic and breadboard-diagram
  generation and auto-layout engine, previously embedded inside
  dudhya (old-smartphone revival), now its own independent project.
* The engine had already been tested against three genuinely
  different circuits (one real, two synthetic) with real, automated
  verification before extraction -- a reasonable bar for "this
  generalizes."
* Flat filesystem structure: every source file at the project root,
  no subdirectories at all.
* Two self-contained example circuits (example_circuit1.py,
  example_circuit2.py), with real, verified symbol pin geometry
  (example_pins.py) kept independent of any downstream project.
* Fixed: a real bug found while re-verifying the example circuits
  through the breadboard-side algorithm for the first time -- a row-
  capacity overflow was crashing with an unhandled exception instead
  of failing cleanly. The crash risk is fixed; the deeper root cause
  is honestly documented as an open item, not papered over.
* Fixed: a small, unrelated corrupted-word bug in batch-init.el,
  found along the way.
* Full documentation set: Constitution.org, Concept.org,
  DevelopmentStandard.org (including the complete KiCad environment
  setup procedure and the engine's own technical development
  history), ResearchJournal.org (the relevant history reproduced from
  dudhya's own journal, plus the extraction's own account),
  FutureResearch.org, Index.org, SessionHandoff.org.
