Repository navigation
The pad: where a component's terminals become copper - #8369
Conversation
gunbai-bot
Bot
changed the title
|
Moving this back to draft on my own judgement, not because of a defect in it. The side-chat ruling reverses the order I proposed, and it is right. Pad, Footprint and their admission all carry NetIdentity, ComponentInstanceIdentity and TerminalIdentity, which are board-global branded strings today: VCC on one board is structurally the same net as VCC on another. The design-identity axis has to thread through every one of those carriers. Landing this first means adding construction sites that the identity migration then has to widen, which is the cost DESIGN section 3 prices when it says a replacement is planned from the root rather than by growing the old shape first. So the order is: ELECTRICAL-DESIGN-IDENTITY-0 lands the board-scoped identities and the cross-board replay refusal, then this rebases onto them, then it grows the parts the ruling asks for and that this cut does not have — plated-hole and mechanical-hole distinct from SMT pad, pin-one and orientation standing, and admission against an exact board revision. The second correction I am taking with it: this was authored as a carrier with every real component left pending, and the ruling is explicit that a footprint PR must establish at least one actual footprint in the real Altra world. It will not come back out of draft until it does. — sent from zesty-heron-736 |
Placement establishes where a component's BODY sits. Copper establishes which net is realized on which layer. Nothing joined them -- no carrier said that THIS terminal of THIS component is a conductor at THIS coordinate on THIS layer. That gap is why the plan view renders bodies and no traces, and it is measurable: zero occurrences of 'terminal' anywhere in the Altra placement module. It also meant the board could not refuse the interesting way. A net whose members name terminals no pad realizes is unroutable, and before this the fact had no representation, so it could not be observed, counted or refused. THE UNIT IS THE PAD, NOT THE PIN NUMBER. A pin number is a vendor indexing convention that differs between the package drawing, the schematic symbol and the netlist, so comparing two of them by number is the spelling coincidence DESIGN section 3 forbids. A pad names the TerminalIdentity the connectivity model already uses, so 'is this pad on that net' is the same decidable join the net relation performs. Proven by sabotage rather than asserted: replacing the component-qualified join with a terminal-identity-only comparison -- exactly the pin-number comparison this module refuses -- turns w_red_a_pad_on_another_component_does_not_satisfy_the_member FAIL while the positive case still passes. A CITATION IS REQUIRED, not optional. Pad coordinates are a manufacturer's recommended land pattern; authored without a source they are someone's recollection of a drawing and a board built to them does not solder. An Absent arm would invite filling the gap from memory, so drawing_authority is plainly required with no legacy arm, and it names a resolvable symbol rather than a document title. Four refusals, each counted and located: a net member with no pad (naming component and terminal, not just the net), two pads on one terminal, a pad selected against another board's stackup, and two footprints for one component. AdmittedFootprints is sole_constructor with one admit_callers- sealed mint. Footprint admission is deliberately SEPARATE from copper's: it asks whether the roster can be routed at all, copper asks whether the conductors someone drew are consistent. Fusing them would make 'there are no pads yet' indistinguishable from 'the routing is wrong'. 6 witnesses PASS (5 RED controls). Compile gate: 32 hard diagnostics, all pre-existing, none naming any file this change touches. Stacked on #8363 -- product.electrical.connectivity is its dependency. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…equality #8372 made ComponentInstanceIdentity a design-scoped record, so this branch's string casts stopped holding. The fixture now mints its component identities against a fixture design, and component_has_duplicate_footprint compares through component_identity_eq instead of casting both sides to NonEmptyStr -- which is the same correction the design axis forced everywhere else, and it means two boards' components with one local label can no longer read as one duplicated footprint. Reset onto main and cherry-picked this branch's own delta rather than merging: #8363 and #8372 both squash-merged, so the stacked history's diff against main had become a reversion of the work that just landed. 6 witnesses pass. Compile gate: 0 blocking errors. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
05dc9c1 to
e9d0c25
Compare
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
1 participant
Placement establishes where a component's body sits. Copper establishes which net is realized on which layer. Nothing joined them — no carrier said that this terminal of this component is a conductor at this coordinate on this layer.
That gap is why the plan view renders bodies and no traces, and it is measurable: zero occurrences of
terminalanywhere in the Altra placement module. It also meant the board could not refuse the interesting way — a net whose members name terminals no pad realizes is unroutable, and the fact had no representation, so it could not be observed, counted, or refused.The unit is the pad, not the pin number
A pin number is a vendor indexing convention that differs between the package drawing, the schematic symbol and the netlist, so comparing two of them by number is the spelling coincidence DESIGN section 3 forbids. A pad names the
TerminalIdentitythe connectivity model already uses, so "is this pad on that net" is the same decidable join the net relation performs.Proven by sabotage, not asserted: replacing the component-qualified join with a terminal-identity-only comparison — exactly the pin-number comparison this module refuses — turns
w_red_a_pad_on_another_component_does_not_satisfy_the_memberFAIL while the positive case still passes.A citation is required, not optional
Pad coordinates are a manufacturer's recommended land pattern. Authored without a source they are someone's recollection of a drawing, and a board built to them does not solder. An
Absentarm would be an invitation to fill the gap from memory, sodrawing_authorityis plainly required with no legacy arm, and it names a resolvable symbol rather than a document title.Refusals
Four, each counted and located: a net member with no pad (naming component and terminal, not just the net), two pads on one terminal, a pad selected against another board's stackup, and two footprints for one component.
AdmittedFootprintsissole_constructorwith oneadmit_callers-sealed mint.Footprint admission is deliberately separate from copper's: it asks whether the roster can be routed at all; copper asks whether the conductors someone drew are consistent. Fusing them would make "there are no pads yet" indistinguishable from "the routing is wrong".
Verification
6 witnesses pass, 5 of them RED controls. Compile gate produces 32 hard diagnostics, all pre-existing in
src/v2/lens/complexity_accumulator_copy/analyze.dag, none naming any file this change touches.Stacked on #8363 —
product.electrical.connectivityis its dependency.