alplabai/signex

What happens In the SchLib (.snxsym) editor, all four rows of the Active Bar's Snap dropdown are inert. Clicking "Pin Tips", "Line Endpoints", "Arc Centres" or "Text Origins" does nothing at all — and the dropdown does not even close, which is the tell that separates this from an ordinary not-yet-implemented stub. The other Active Bar dropdowns in the same editor close on click. Where crates/signex-app/src/library/editor/symbol/active_bar/dropdowns.rs:134-169: fn snap_entries(path: PathBuf) -> Vec<DropdownEntry<LibraryMessage>> { let _ = path; // SchLib snap surface is simpler than footprint — pin tips, line // endpoints, arc centres, text origins. All stubs until the // SchLib snap subsystem ships. vec![ DropdownEntry::Header("Snap targets".into()), DropdownEntry::Item(DropdownItem::new( "Pin Tips", LibraryMessage::PrimitiveEditorEvent { path: PathBuf::new(), msg: PrimitiveEdit::Symbol(Symb

Context Signex publishes checksums with every release (SHA256SUMS.txt, release.yml:206-210) but no software bill of materials. Searching the repo for sbom, cyclonedx, syft, or cargo-auditable finds only SPDX licence headers on source files — no SBOM generation anywhere. This fits work the project already does rather than adding a new concern. deny.toml and the deny · licenses + deps CI job already enforce dependency licensing as a hard gate (ci.yml:108-136), and docs/LICENSING.md plus a 22 KB license-guard.yml show the project takes dependency provenance seriously. An SBOM is that same information, published in a form downstream consumers can actually consume — and for an Apache-2.0 tool that engineering organisations will vendor into their own supply chains, being able to answer "what is in this binary" without building it is worth having. This is not v1.0-gating. It does not block any exit criterion. It is a small, well-bounded improvement to a release pipeline that is otherwise

Context Nothing checks that Signex's version numbers agree with each other, and they have drifted repeatedly as a result: Cargo.toml:44 says version = "0.14.0". The newest tag is v0.13.0. v0.14.0 was never tagged. v0.12.0 never existed as a release either — planned, merged, never tagged. README.md:12 badges a link to releases/tag/v0.14.0, which 404s, because that tag does not exist. The project's front page links to a missing release. CHANGELOG.md:6 states the problem outright: a missing CHANGELOG section is not an error, the release workflow silently falls back to auto-generated notes, and the enforcement the file used to cite (.claude/hooks/pre-release-guard.sh) is gitignored and does not exist. docs/ROADMAP.md:47-69 tracks the resulting drift as a known gap, and notes the roadmap itself "drifted six versions away from reality" before being reconciled by hand. Every one of those is the same missing guard. The release workflow's CHANGELOG extractor (release.yml:212-255) is deliber

Context The corpus harness covers .snxpcb as well as .snxsch, but ships with only a couple of board fixtures. This task fills in the PCB half of the 50+ the v1.0 gate calls for. Good news for whoever picks this up: crates/signex-types/src/pcb.rs contains no HashMap, so the .snxpcb writer is already key-order-stable. Unlike the schematic side, this task is not blocked on a determinism fix — the fixtures should be byte-stable as soon as you author them. If one is not, that is a real finding: report it rather than working around it. Scope Add fixtures covering at minimum one each. Consult crates/signex-types/src/pcb.rs and crates/signex-types/src/format/pcb_rows.rs for the authoritative variant lists: empty board; a board with only an outline; a board with a non-default thickness a layer stackup; a populated setup nets — including a net with no pads attached a footprint with pads; a footprint at a non-zero rotation; a footprint on the bottom layer one fixture per PadType variant

Context The corpus harness walks crates/signex-types/tests/corpus/ but ships with only a handful of seed fixtures. The v1.0 gate calls for 50+ native .snx* projects round-tripping cleanly. This task covers the schematic half. Each fixture is a checked-in .snxsch that the harness parses, re-serialises, and byte-compares against the file on disk. Authoring one is cheap: build the sheet in a small helper, run the harness in bless mode to emit the file, eyeball the output, commit it. From then on the file is the golden and any format drift shows up as a diff. The value is coverage of the feature matrix: today's in-memory tests exercise a handful of shapes, so a regression in any untested corner of the format lands silently. Scope Add fixtures covering at minimum one each. Consult crates/signex-types/src/schematic/mod.rs and sheet.rs for the authoritative field and variant lists: empty sheet; single symbol; a symbol with every TSV row column populated a symbol whose data lives only in ex