init

docs/adr/0001-defects-are-about-the-board-not-project-work.md

@@ -0,0 +1,9 @@
+# A Defect is about the Board artifact, not the reporter's project work
+
+An Andon system normally signals a problem in the *work* being done; a reader could reasonably assume a click on a Section classifies a project problem under a Lean category (and aggregates to "which practices are weakest"). We decided the opposite: a **Defect** is feedback about the **physical Board itself** — a Section that is confusing, out of date, redundant, or missing — because the Board is the product we are rolling out company-wide and we want to find its weak points (Dantotsu) before/while scaling it.
+
+## Consequences
+
+- A **Section** that accumulates Defects is a **Weak Point of the Board**, not of a delivery team.
+- The dashboard's red-dot map ranks *Board sections*, not project practices.
+- If we later want to capture project-level problems too, that is a *different* concept and should not be conflated with Defect.

docs/adr/0002-attribution-is-transparent-not-blameless.md

@@ -0,0 +1,8 @@
+# Attribution is transparent, not blameless
+
+The Toyota/Andon norm is that pulling the cord is **blameless** — reporters are never named, so no one hesitates to signal a problem. We deliberately deviated: the **Reporter**'s `@theodo.com` identity (from SSO) is stored *and shown on the dashboard*. The bet is that Theodo's high-trust culture makes naming a source of accountability and follow-up rather than fear, and that visible authorship raises the quality of verbatims.
+
+## Consequences
+
+- This is a cultural risk: if reporting volume is low or verbatims become guarded, revisit and consider hiding the Reporter (the data is already captured, so only the display would change — relatively reversible).
+- Combined with the dashboard being open to all `@theodo.com` (visual management), every defect is attributable company-wide.