PRINT-0..4: printed node chassis — subject, printer, measurement, coupon and contract authorities

dag/extdeps/boards/asrock_rack.dag

@@ -31,9 +31,13 @@ import extdeps.firmware.types {
   InstantFlashRom,
   firmware_semantic_version,
 }
-import std.measure { ByteSize, MegatransfersPerSecond, byte_size, celsius, megatransfers_per_second, percent, positive_celsius_delta, positive_measure_count }
-import extdeps.external_authority { ExternalAuthority, ExternalModelScope, ExternalSubjectRef }
+import std.measure { Micrometer, micrometer, ByteSize, MegatransfersPerSecond, byte_size, celsius, megatransfers_per_second, percent, positive_celsius_delta, positive_measure_count }
+import extdeps.external_authority { ExternalAuthority, ExternalModelScope, ExternalSubjectRef, FactCitation }
+import std.coordinate_frame { CoordinateFrameIdentity, coordinate_frame_identity }
+import std.affine_space { point2 }
+import std.orthogonal_geometry { AxisAlignedRectangle2, OrthogonalConstruction, axis_aligned_rectangle2 }
 import std.decl_ref { DeclarationRef, WholeDeclaration }
+import extdeps.standards.atx_2_2 { MountingLocationId, LocB, LocC, LocF, LocH, LocJ, LocL, LocM, LocR, LocS }
 import extdeps.cpu.types { CpuSocket }
 import extdeps.cpu.ampere { ampere_lga4926_socket }
 import extdeps.uri { Uri, Https }
@@ -571,3 +575,162 @@ data asrock_altrad8ud_1l2t_mechanical: AsrockAltrad8ud1l2tMechanical = AsrockAlt
 }
 
 data asrock_altrad8ud_channel_note: NonEmptyStr = "Eight DIMM slots at one DIMM per channel on the vendor page - the board exposes eight of the SoC's memory channels, so the one-DIMM-per-channel population IS the full population; there is no second-DIMM headroom on this platform, unlike the 16-slot dual-socket boards and the 32-slot 2DPC systems."
+
+// ---------------------------------------------------------------------------------------------
+// BOARD GEOMETRY, read first-party from the vendor manual this module already cites.
+//
+// PROVENANCE, stated before the numbers because it is the fact that decides how they may be used.
+// extdeps_external_authority_anchor names download.asrock.com/Manual/ALTRAD8UD-1L2T.pdf. That
+// document was FETCHED AND READ by the authoring session — download.asrock.com answers 200 from
+// this environment, unlike the general web, which is refused — so these are a first-party read of
+// the manual and not the relayed grade extdeps.climbing_holds.atomik is stamped with. Section 1.4
+// "Motherboard Layout" carries the outline as leader dimensions: 26.7 cm (10.5 in) by 24.4 cm
+// (9.6 in).
+//
+// WHAT THIS REPLACES. asrock_altrad8ud_1l2t_mechanical carries form_factor_label, a String reading
+// "deep micro-ATX (9.6 x 10.5 in)". That row states a MEASUREMENT in prose, which DESIGN §4c names
+// as the thing a typed carrier must hold instead — a String cannot be asked whether a chassis panel
+// clears the board. The label is left standing because it also carries a FORM-FACTOR CLAIM, which
+// is a different fact from an outline and is not established by these two lengths.
+//
+// THE AXES, AND AN ERROR THIS FILE SHIPPED ONCE. The board is 244 mm ALONG THE REAR I/O EDGE and
+// 267 mm DEEP: the manual prints 24.4 cm (9.6 in) and 26.7 cm (10.5 in), and the vendor calls the
+// form factor "deep micro-ATX (9.6 x 10.5 in)".
+//
+// An earlier revision transposed these and asserted the board was 267 mm WIDE against micro-ATX's
+// 244 mm, concluding that a micro-ATX hole pattern would be laid out 23 mm too narrow. That was
+// backwards and the conclusion inverts. Deep micro-ATX keeps the micro-ATX rear-I/O WIDTH exactly
+// and extends the DEPTH — extdeps.standards.atx_2_2 deep_micro_atx_axis_note carries the relation —
+// so the rear-edge hole columns are the standard micro-ATX ones and it is the FRONT row that moves
+// outward by the extra 0.9 in. The error mattered: it is the difference between "the standard
+// pattern does not apply" and "the standard pattern applies except at known positions".
+//
+// The outline is still NOT a conformance claim. Matching two edge dimensions is not the same as
+// carrying the specification's hole grid, and extdeps.standards.atx_2_2 deliberately does not
+// supply that grid either — the specification places the holes in a figure with no text layer.
+// ---------------------------------------------------------------------------------------------
+fn asrock_altrad8ud_board_frame() -> CoordinateFrameIdentity { coordinate_frame_identity(occurrence: 31) }
+
+// Micrometres, for the reason std.spatial_frame records and extdeps.printing.fdm repeats: the
+// quantum is chosen from the smallest distinction the frame must preserve, not from the largest
+// value it must hold. Whole millimetres are sufficient for these two extents and are NOT sufficient
+// for what will be drawn in this frame next — DIMM slot pitch and standoff positions — and a frame
+// whose quantum is retro-fitted after coordinates exist in it silently rescales every one of them.
+// x is ALONG THE REAR I/O EDGE (244 mm), y is DEPTH FROM THAT EDGE (267 mm). The axis assignment is
+// stated here because the frame carries no axis names and the numbers alone do not disclose which is
+// which — which is exactly how the transposition above survived review the first time.
+fn asrock_altrad8ud_board_outline() -> OrthogonalConstruction<AxisAlignedRectangle2> {
+  axis_aligned_rectangle2(
+    min: point2(frame: asrock_altrad8ud_board_frame(), x: 0, y: 0),
+    max: point2(frame: asrock_altrad8ud_board_frame(), x: 244000, y: 267000)
+  )
+}
+
+data asrock_altrad8ud_board_outline_citation: FactCitation = FactCitation {
+  fact: DeclarationRef {
+    module_path: "extdeps.boards.asrock_rack",
+    decl_name: "asrock_altrad8ud_board_outline",
+    field: WholeDeclaration
+  },
+  authority: extdeps_external_authority_anchor
+}
+
+// THE MOUNTING HOLES ARE NOT HERE, AND THEIR ABSENCE IS THE POINT.
+//
+// Section 1.4 draws the standoff holes as unlabelled circles on the layout figure and dimensions
+// NONE of them: the manual states the outline and stops. So the coordinates a chassis actually
+// needs are, for this subject, an OBLIGATION and not a fact — and this module refuses to hold them
+// rather than deriving them from the micro-ATX pattern the form-factor label gestures at. That
+// derivation is available, plausible, and would be wrong in a way nothing downstream could detect:
+// it would place standoffs against a 244 mm-wide pattern on a 267 mm-wide board, produce a chassis
+// that assembles until the last two screws, and cite this manual while doing it.
+//
+// DESIGN §5's absorbing fallback is precisely this move — substituting the superset, or the nearby
+// standard, when the precise answer is unavailable — so the arm refuses and names what would clear
+// it. The operator holds four of these boards and four more are inbound; caliper positions from a
+// declared origin corner are a first-party measurement, admissible at the OperatorMeasured grade
+// that extdeps.ampere.mt_collins_product_brief.platform already establishes for a tape-measured
+// chassis depth. That is the trigger: measured standoff coordinates, not a second reading of this
+// manual, which does not contain them.
+// ---------------------------------------------------------------------------------------------
+// THE STANDOFF POSITIONS: A CORRESPONDENCE TO THE MICRO-ATX GRID, NOT A SET OF READ COORDINATES.
+//
+// AN EARLIER REVISION OF THIS BLOCK GOT THE EPISTEMICS WRONG IN THE CONSERVATIVE DIRECTION, which is
+// still wrong. It recorded all seven holes as estimates with a +/- 0.4 in region, reasoning that
+// they came from reading a figure. But the readings land exactly on 0.250, 6.450, 8.250, 9.050,
+// 6.500 and 9.350 — the micro-ATX grid's own values — and two near-misses (1.29, 0.39) are raster
+// approximations of 1.300 and 0.400. Values do not land on nine standard coordinates by accident.
+//
+// So the reading is not evidence about WHERE the holes are. It is evidence for a different
+// proposition: that this board POPULATES those named standard locations. The coordinates themselves
+// are exact and come from extdeps.standards.atx_2_2, not from any pixel. Treating registration
+// evidence as coordinate uncertainty put a +/- 10 mm region on numbers that are known to the
+// thousandth of an inch, and would have forced a slotted carrier where a drilled hole is justified.
+//
+// WHAT REMAINS INFERRED is the correspondence itself: ASRock does not dimension these holes or name
+// them by letter, so "this board's visible hole IS standard location C" is a strongly supported
+// inference from a to-scale drawing, not a vendor statement. It is discharged physically at FIT.
+//
+// J AND S ARE PROHIBITIONS, NOT ABSENCES, and this is the distinction that has a short circuit at
+// the end of it. Both are standard micro-ATX locations. Neither carries a board hole here. A chassis
+// built to the full micro-ATX population puts a metal standoff at each, under a board with copper
+// and no hole above it. "Not in my list of holes" and "must not be populated" were the same state in
+// the earlier model; they are now different constructors, because only one of them is a warning.
+// ---------------------------------------------------------------------------------------------
+
+data asrock_altrad8ud_standoff_figure_authority: ExternalAuthority = ExternalAuthority {
+  uri: Uri {
+    scheme: Https
+    locator: "drive.google.com/file/d/1z36tmUWAwOwXWy6ASmaPWJNzKoZggBs8/view"
+  }
+}
+
+type BoardLocationDisposition
+  = BoardHolePresent
+  | ChassisStandoffForbidden
+
+type BoardStandardLocationCorrespondence sole_constructor {
+  location: MountingLocationId
+  disposition: BoardLocationDisposition
+}
+
+fn board_location_correspondence(
+  location: MountingLocationId,
+  disposition: BoardLocationDisposition,
+) -> BoardStandardLocationCorrespondence {
+  BoardStandardLocationCorrespondence { location: location, disposition: disposition }
+}
+
+// Coordinates are deliberately ABSENT from these rows. A correspondence names a location; the
+// location owns its position. Copying the coordinates here would fork the grid — the exact defect
+// this session already paid for once, where the coupon's holes were computed a second time instead
+// of being read from the ladder that defined them.
+data asrock_altrad8ud_standard_location_correspondence: List<BoardStandardLocationCorrespondence> = [
+  board_location_correspondence(location: LocF, disposition: BoardHolePresent),
+  board_location_correspondence(location: LocM, disposition: BoardHolePresent),
+  board_location_correspondence(location: LocC, disposition: BoardHolePresent),
+  board_location_correspondence(location: LocH, disposition: BoardHolePresent),
+  board_location_correspondence(location: LocL, disposition: BoardHolePresent),
+  board_location_correspondence(location: LocB, disposition: BoardHolePresent),
+  board_location_correspondence(location: LocR, disposition: BoardHolePresent),
+  board_location_correspondence(location: LocJ, disposition: ChassisStandoffForbidden),
+  board_location_correspondence(location: LocS, disposition: ChassisStandoffForbidden),
+]
+
+data asrock_altrad8ud_correspondence_evidence: NonEmptyStr = "Scale reading of the section 1.4 motherboard-layout figure via an operator-supplied grid overlay (cited above). The figure's outline is to scale, measured aspect ratio 1.0935 against 10.5/9.6 = 1.0938. Seven marked holes land on micro-ATX grid values; J is marked on the figure as a standoff to remove; S is not drawn and is inferred absent. This establishes WHICH standard locations the board populates. It does NOT establish the coordinates, which are the standard's, and it is not a vendor statement of conformance."
+
+// THE DEEP EXTENSION, and the cassette requirement that falls out of it.
+//
+// The front mounting row L/M sits at 9.350 in from the rear edge — the ORDINARY micro-ATX position,
+// not a moved one. An earlier revision of this file claimed the extra depth pushed that row outward
+// from a nominal 8.95; it does not. 8.950 is measured from Datum B, which is itself 0.400 in from
+// the board edge, so 0.400 + 8.950 = 9.350 on a standard-depth board and on this one alike.
+//
+// What the extra depth does is leave board hanging PAST the last mounting row: 10.500 - 9.350 =
+// 1.150 in, 29.21 mm, against 0.250 in on an ordinary micro-ATX board. Power and SlimSAS connectors
+// sit near that edge and take insertion force on unsupported PCB. A non-conductive front-edge
+// support is therefore a cassette candidate rather than a nicety — gated on an underside-component
+// keep-out measurement, since a support that fouls a solder joint is worse than none.
+data asrock_altrad8ud_front_overhang: Micrometer = micrometer(count: 29210)
+
+data asrock_altrad8ud_standoff_measurement_obligation: NonEmptyStr = "STILL OPEN, and narrower than it was: the standard LOCATIONS are exact, so what remains unmeasured is product-specific. (1) Physical confirmation that each visible hole is the named standard location — discharged at FIT by mounting the board. (2) This board's actual hole diameter: the standard's 3.96 mm belongs to the location definition, not to the product. (3) Underside component and copper keep-outs around each hole. (4) Whether any mounting hole is bonded to board ground, which the protective-earth requirement makes load-bearing rather than trivia, since the earth path runs through the standoffs. (5) Standoff height and permissible contact-pad diameter."

dag/extdeps/printing/bambu_studio.dag

@@ -0,0 +1,118 @@
+module extdeps.printing.bambu_studio
+
+import std.types { List, NonEmptyStr }
+import std.decl_ref { DeclarationRef, WholeDeclaration }
+import std.os.types { OperatingSystemProduct, UbuntuOs, WindowsOs, MacosOs, NobleNumbat2404Lts, Windows1124H2Build26100, Sequoia15 }
+import extdeps.external_authority { ExternalAuthority, ExternalModelScope, ExternalSubjectRef }
+import extdeps.uri { Uri, Https }
+
+// Bambu Studio, the vendor's own slicer, as its OWN subject — not a field on the printer. DESIGN §3
+// external decomposition: the slicer is independently versioned from the machine it slices for, and
+// OrcaSlicer, its fork, is a third subject again. A printer module that enumerated its slicers would
+// be the generic-hub violation that rule names.
+data extdeps_external_authority_anchor: ExternalAuthority = ExternalAuthority {
+  uri: Uri {
+    scheme: Https
+    locator: "github.com/bambulab/BambuStudio"
+  }
+}
+
+data bambu_studio_product_page_authority: ExternalAuthority = ExternalAuthority {
+  uri: Uri {
+    scheme: Https
+    locator: "bambulab.com/en/download/studio"
+  }
+}
+
+data bambu_studio_release_api_authority: ExternalAuthority = ExternalAuthority {
+  uri: Uri {
+    scheme: Https
+    locator: "api.github.com/repos/bambulab/BambuStudio/releases/latest"
+  }
+}
+
+data bambu_studio_flathub_authority: ExternalAuthority = ExternalAuthority {
+  uri: Uri {
+    scheme: Https
+    locator: "flathub.org/apps/com.bambulab.BambuStudio"
+  }
+}
+
+data extdeps_model_scope: ExternalModelScope = ExternalModelScope {
+  subject: ExternalSubjectRef {
+    declaration: DeclarationRef {
+      module_path: "extdeps.printing.bambu_studio",
+      decl_name: "bambu_studio_platform_support",
+      field: WholeDeclaration
+    }
+  },
+  first_citation: extdeps_external_authority_anchor,
+  further_citations: [bambu_studio_release_api_authority, bambu_studio_flathub_authority],
+}
+
+// TWO AUTHORITIES FROM ONE VENDOR DISAGREE, AND THE MODEL CARRIES BOTH RATHER THAN PICKING.
+//
+// The A1 mini specification table, relayed by the operator from the product page, states the slicer's
+// supported operating systems as "MacOS, Windows". The vendor's own release feed, fetched
+// first-party from this environment, publishes BambuStudio_ubuntu22.04-*.AppImage and
+// BambuStudio_ubuntu24.04-*.AppImage as release assets, and Flathub serves the application. Both are
+// the vendor speaking. They do not agree.
+//
+// WHY NOT JUST RECORD "LINUX IS SUPPORTED". Because that resolves a disagreement this repository
+// has no authority to resolve, and it discards the fact that is actually load-bearing for an
+// operator: the SPEC SHEET does not promise Linux, so a Linux regression is not a warranty claim,
+// while the RELEASE FEED demonstrably ships Linux binaries, so the toolchain can be Linux-native
+// today. A consumer planning a Linux workstation needs the second; a consumer deciding what the
+// vendor is contractually committed to needs the first. Collapsing to one erases the other, and the
+// collapse would be invisible — the surviving row looks equally authoritative either way.
+//
+// This is the shape DESIGN §3 calls a MEANING FORK if it were left implicit: one spelling
+// ("supported OS") carrying two materially different obligations. Naming the two claims separately,
+// each with its own authority, is what keeps it from being one.
+type PlatformSupportClaimKind
+  = SpecificationSheetClaim
+  | PublishedReleaseArtifact
+
+type PlatformSupportClaim sole_constructor {
+  kind: PlatformSupportClaimKind
+  platform: OperatingSystemProduct
+  authority: ExternalAuthority
+  note: NonEmptyStr
+}
+
+data bambu_studio_spec_sheet_platforms: List<PlatformSupportClaim> = [
+  PlatformSupportClaim {
+    kind: SpecificationSheetClaim,
+    platform: MacosOs { distro: Sequoia15 },
+    authority: bambu_studio_product_page_authority,
+    note: "A1 mini specification table, 'Slicer Supported OS: MacOS, Windows', relayed by the operator 2026-09-01. The table names the OS family without an edition; Sequoia15 is this corpus's macOS surface row and is NOT part of the vendor's claim.",
+  },
+  PlatformSupportClaim {
+    kind: SpecificationSheetClaim,
+    platform: WindowsOs { distro: Windows1124H2Build26100 },
+    authority: bambu_studio_product_page_authority,
+    note: "Same table, same relay. Edition is this corpus's Windows surface row and is not stated by the vendor table.",
+  },
+]
+
+// Fetched first-party: api.github.com answers 200 from this environment, so these asset names were
+// READ, not relayed. The release carrying them is v02.08.02.61. Ubuntu 22.04 is also published; only
+// the 24.04 asset is modelled here because NobleNumbat2404Lts is the surface row this corpus carries,
+// and inventing a 22.04 row to be complete would mint an OS product for a claim nothing consumes.
+data bambu_studio_release_artifact_platforms: List<PlatformSupportClaim> = [
+  PlatformSupportClaim {
+    kind: PublishedReleaseArtifact,
+    platform: UbuntuOs { distro: NobleNumbat2404Lts },
+    authority: bambu_studio_release_api_authority,
+    note: "Release asset BambuStudio_ubuntu24.04-v02.08.02.61-*.AppImage, read first-party from the release API 2026-09-01. Flathub additionally serves com.bambulab.BambuStudio.",
+  },
+]
+
+data bambu_studio_platform_support: List<PlatformSupportClaim> = concat(
+  bambu_studio_spec_sheet_platforms,
+  bambu_studio_release_artifact_platforms
+)
+
+// The disagreement stated as a fact of its own, so a reader who consults only one list is told the
+// other exists. It is NOT a resolution: no arm of this module says which claim wins.
+data bambu_studio_platform_claim_divergence: NonEmptyStr = "The vendor's specification table and the vendor's release feed disagree about Linux. The table lists macOS and Windows only; the release feed publishes Ubuntu 22.04 and 24.04 AppImages and Flathub serves the application. Both are cited above with separate authorities and separate claim kinds. This repository does not adjudicate between them: a Linux toolchain is demonstrably available, and is not promised by the specification sheet."