main
John Lauer 0.1.36: the fab is written as 3rd party fab in docs, skills, flows and run logs; profile inhouse renamed fab 3750e82 6d ago

Silkscreen priorities and review passes

Treat silkscreen as a physical user interface for the EE assembling, wiring and debugging this specific board. The AI identifies intent and importance; deterministic geometry proves that the selected text and strokes fit. Explain decisions and exceptions with source data and short rationale, not private chain-of-thought.

The order below is explicit: a lower priority cannot buy a collision, incorrect label, hidden text or missing required value.

  1. Physical correctness. Use actual numbered pad nets and verified component values. Include board edges, fitted component bodies, full custom-pad mask geometry, all holes/vias, native footprint artwork, other text and actual pointer/frame stroke widths as obstacles. Never infer voltage/current ratings from a part's absolute maximum or an unqualified solver estimate.
  2. Coverage and field use. Label all required references, smaller values, test-point functions, polarity, connector pins and machine contacts/pins. Put contact/edge-connector identities and functions on BOTH faces near the actual feature; a remote table is supplementary.
  3. Board-purpose importance. Before placement, classify the board and rank its human interfaces. On ESCs, prominently label PHASE A/B/C and battery polarity/ground. Other boards get their own appropriate prominent interfaces, supply limits and critical warnings. Functional terminal names may outrank MC/J references. Use only sourced descriptions/limits.
  4. Locality and association. Keep each name/value pair atomic and close to its component. For edge contacts prefer the space between contact and board edge, consistently across a row; use inside placement only when needed. Pin labels face their target: right-aligned left of the pad, left-aligned right of it, reversed appropriately for a readable bottom-face view. Use curved pointers when association is unclear.
  5. Group design. Repeated contact frames default on, with a user-off option. Solve common left/right rails, width/height, padding and rhythm for a row/column. Do not stretch a frame after checking collisions. Clearance gaps and exceptional font/inside placements are explicit. Calculation bounds are dashed and translucent; only actual manufacturing text/pointers/frames are opaque solid strokes.
  6. Readable typography. Maximize font size within the above constraints. Start ordinary references around 0.8 mm and values around 0.4 mm, with values smaller than references. Important interfaces often justify 1.0–1.4 mm or more where space permits. The user-authorized 3rd party fab 0.3/0.2 mm value text is a last resort, not a default or a general fabrication guarantee. Document the selected sizes and any tiny-text compromise.
  7. Interior documentation pass. Reserve readable open INTERIOR regions for a source-backed board description, identity/revision, service instructions and reference tables. Prefer an interior layout at a readable font over a slightly larger edge layout. Keep physical terminal labels local. Preserve semantic blocks, left-aligned visible text, heading hierarchy and ordered rows. Reflow or split a large table into coherent columns before pushing it to the rim. Slight, quantized row-spacing increases may avoid vias; do not move lines independently or reorder them. If the middle cannot fit safely, report the blocking geometry, attempted sizes and explicit edge fallback. Include what the board does, not just a project code.
  8. Independent verification and final visual pass. Check every text and stroke ahead of the EDA, then native DRC and native text/geometry read-back. Inspect top and bottom in both the editor and its refreshed 3D viewer. Review left alignment, common rails, name/value hierarchy, pin-1/polarity, no text hidden by bodies, no holes under text, and whether documentation uses interior space sensibly. Repair the general rule when a native check reveals a defect.
  9. Evidence. Replay all required groups and real rework with active text sizes. Isolate faces and show the bottom from below (or explicitly mirrored from above). Record 1920×1080; frame the complete active group independently of manual inspection camera movement. Include final native EDA proof. Inspect contact sheets and actual webview playback. Never describe the replay as recorded internal AI reasoning or omit unresolved decisions from the report.

Report separately: coverage, geometric validity, native verification, visual association/readability, source handoff and actual shared-package release. Passing DRC alone is not production acceptance.