silicon-grade-disciplinelisted

# Silicon-Grade Discipline ## Overview Software bugs ship a patch. Hardware bugs ship a respin, or a recall, or a dead board on a bench you can't reach. That asymmetry changes how you write code in this domain: correctness is not negotiable against speed, because the cost of wrong is measured in mask sets and weeks. **Core principle:** A failure must be loud, a check must be honest, and a fix must address the root cause. The most dangerous output in this domain is a green checkmark over a real defect. ## When to Use - Writing or reviewing code that drives, verifies, or generates hardware - Tempted to add a flag that makes a failing check pass - Tempted to add recovery scaffolding for a failure mode you haven't diagnosed - Deciding between `panic`/`assert` and returning an error - Deciding how much test coverage is enough This skill is the shared backbone; the domain skills (`hdl-module-design`, `tapeout-precheck`, `differential-verification`, and others) lean on it. ## Failures Should Fail Never add a knob that converts a real failure into a pass. No `ERROR_ON_DRC=false`, no `--skip-lvs`, no `if (mismatch) verdict = pass`, no "temporarily" commented-out assertion. Those don't fix the problem; they hide it and then ship it. - A failing check means the design or the code is wrong. Fix the thing being checked. - A legitimate exception is explicit, recorded, and granted by the authority that owns the rule (the foundry, the spec), with its rationale written down. It is ne