Hardware repository anatomy

A hardware repository should make the design reproducible without turning every generated file into canonical source.

project/
├── README.md
├── board.kicad_pro
├── board.kicad_sch
├── board.kicad_pcb
├── lib/
│   ├── symbols/
│   ├── footprints/
│   └── 3dmodels/
├── mechanical/
│   ├── enclosure.step
│   └── constraints.md
├── scripts/
├── reports/
└── fab/
    └── r1.0/
        ├── manifest.json
        ├── CHECKSUMS.sha256
        └── outputs/

Canonical source

Schematics, PCB layouts, project libraries, scripts, and hand-authored constraints belong in Git. They are the inputs required to understand and reproduce the board.

Generated evidence

DRC/ERC reports, renders, BOMs, placement files, Gerbers, and drill files are outputs. Keeping a release snapshot is useful, but it must identify the source commit and tool versions that produced it.

Large files

STEP assemblies and high-resolution renders can outgrow ordinary Git quickly. fabPlane keeps durable Git data behind the Git backend and generated artifacts behind the object-storage boundary. The two namespaces are deliberately separate.