Add Designish directory structure standards and definitions

README.md

@@ -46,6 +46,19 @@ Why do we need directory standards?
   Most directories are named after the file-type
   (i.e. suffix or software) they contain.
 
+- [Designish](mod/designish/README.md) (**lifecycle-driven**):
+  Built around the **product lifecycle** and the **design process**.
+  Directories are named after the *phase* a file belongs to,
+  not the file type it contains — making a project's maturity and
+  progress immediately visible to contributors of all backgrounds,
+  including designers with no prior Git experience.
+  Top-level numbered areas (`10_management/`, `20_legal/`,
+  `30_engineering/`, `40_stewardship/`, `50_usage/`) provide a
+  clear visual progress map, while a 5-phase creative pipeline
+  inside `30_engineering/` guides teams from concept to release.
+  A dedicated `40_stewardship/` section covers maintenance, repair,
+  and recovery — supporting circular economy principles.
+
 ## Other structure templates
 
 - <https://www.sciencedirect.com/journal/hardwarex>

designish-structure.md

@@ -0,0 +1,107 @@
+# Designish — OSH Project Directory Structure (Circular & Lifecycle-Driven)
+
+**Principle:** "Process over product" — lifecycle-driven, designer-friendly, and circular.
+
+The **Designish** standard is built around the **product lifecycle** and the **design process**. Instead of naming directories after file types or technical domains, they are named after the **phase** a file belongs to. This approach makes a project's maturity, progress, and sustainability path immediately visible to contributors of all backgrounds.
+
+---
+
+## Naming Rules
+
+- **Numbered prefixes:** `10_`, `20_`, `30_` for top-level areas; `01_`, `02_`, ... for sub-phases.
+
+- **Lowercase with underscores:** `assembly_guide` not `AssemblyGuide` or `assembly-guide`.
+
+- **Descriptive phase names:** `03_make` not `output` or `export`.
+
+
+---
+
+## Directory Tree
+
+
+``` m
+
+root((my-osh-project))
+├── LICENSES/                  # REUSE license files (CERN-OHL, GPL, CC-BY-SA)
+├── README.md                  # Project overview
+├── okh.toml                   # Open Know-How manifest for crawlers & indexers
+├── 10_management/             # The Studio — "Why" and "Who"
+│   ├── 01_roadmap/            # Visual timelines and milestones
+│   ├── 02_meetings/           # Community sync notes (YYYY-MM-DD_topic.md)
+│   ├── 03_stakeholders/       # Map of contributors and community members
+│   ├── input/                 # Incoming briefs and stakeholder requests
+│   └── output/                # Approved plans and mandates
+├── 20_legal/                  # The Safety Net — Open Source protection
+│   ├── compliance/            # CE/FCC certificates and test reports
+│   ├── input/                 # Draft agreements and incoming requests
+│   └── output/                # Signed licenses and legal approvals
+├── 30_engineering/            # The Creative Pipeline — 5-Phase Process
+│   ├── 01_concept/            # The Sketchbook — Ideas & Requirements
+│   │   ├── requirements/      # Functional & sustainability requirements
+│   │   ├── moodboards/        # Visual explorations and block diagrams
+│   │   └── adr/               # Architecture Decision Records (NNN_topic.md)
+│   ├── 02_design/             # The Workbench — Discipline-organized sources
+│   │   ├── electronics/       # Schematics and PCB layouts (KiCad)
+│   │   ├── mechanical/        # 3D CAD (FreeCAD/STEP) and 2D drawings
+│   │   ├── wear_parts/        # Components designed for frequent replacement [NEW]
+│   │   └── firmware/          # The "brain" of the hardware
+│   ├── 03_make/               # The Factory — Everything to build one unit
+│   │   ├── bom/               # Bill of Materials (CSV/MD with material data)
+│   │   ├── assembly_guide/    # Visual step-by-step instructions
+│   │   └── fabrication_files/ # Ready-to-manufacture files (STL, DXF, Gerbers)
+│   ├── 04_validation/         # The Lab — Safety & Prototype testing
+│   │   ├── safety/            # Risk analysis (FMEA)
+│   │   └── test_reports/      # Documentation of what worked or broke
+│   └── 05_release/            # The Gallery — Sharing with the world
+│       ├── oshwa_certification/ # OSHWA compliance evidence
+│       └── media/             # Hero shots, videos, and press kits
+├── 40_stewardship/            # Circularity — Repair & Recovery [NEW]
+│   ├── 01_maintenance/        # Cleaning, calibration, and upkeep logs [NEW]
+│   ├── 02_repair/             # Troubleshooting and disassembly guides [NEW]
+│   └── 03_recovery/           # Recycling paths and upcycling ideas [NEW]
+└── 50_usage/                  # Implementation & Examples
+    └── example/               # Settings, samples, and use-cases
+```
+
+---
+
+## Key Characteristics
+
+|**Property**|**Value**|
+|---|---|
+|**Naming Style**|Lifecycle phase (e.g., `10_management/`, `30_engineering/01_concept/`)|
+|**Modularity**|Flat — single product; sub-assemblies live inside `02_design/`|
+|**Decision Tracking**|ADRs in `01_concept/adr/` — design rationale is first-class|
+|**Circular Focus**|Maintenance, Repair, and Recovery are prioritized in `40_stewardship/` [NEW]|
+|**Handoff Zones**|`input/` and `output/` folders act as zones between disciplines|
+|**Generated Files**|Explicitly separated in `fabrication_files/`|
+
+---
+
+## Why this works for Designers & Circularity
+
+1. **Logical Flow**: Teams move naturally from `01_concept` to `05_release`.
+
+2. **No "Code" Required**: Contributors work in discipline-specific folders using familiar tools.
+
+3. **Sustainability by Design**: By pairing assembly with **disassembly** and **recovery** guides, the project moves from a linear to a circular lifecycle.
+
+4. **Transparency**: Keeping `ADRs` and `test_reports` visible allows the "Trial and Error" process to become a community learning resource.
+
+
+---
+
+## Recommended For
+
+Designer-led teams, sustainable hardware startups, and OSH projects aiming for long-term community stewardship and environmental responsibility.
+
+## References
+
+- `definition.csv` — machine-readable source
+
+- `okh.toml` — Open Know-How (OKH) specification
+
+- `REUSE specification` — License management
+
+- `9R Framework` — Circular Economy principles [NEW]

mod/designish/README.md

@@ -0,0 +1,145 @@
+<!--
+SPDX-FileCopyrightText: 2026 OSH Dir Std Contributors
+SPDX-FileCopyrightText: 2026 Benjamin Götze
+SPDX-License-Identifier: GFDL-1.3-or-later
+-->
+
+# Designish - OSH project directory structure standards
+
+In short: **Lifecycle-driven and designer-friendly**
+
+The basic idea here is that directories are named after the *phase of the
+design lifecycle* they belong to, rather than the file types they contain.
+This makes the project's maturity and progress immediately visible to
+contributors of all backgrounds — including designers with no prior Git
+experience.
+
+The structure follows a 5-phase creative pipeline inside `30_engineering/`,
+preceded by management (`10_management/`) and legal (`20_legal/`) top-level
+concerns.
+
+## Definition
+
+This standards machine-readable definition,
+can be found in various formats here:
+
+- [definition.csv](definition.csv)
+  ([format](../../definition_format.md))
+  \- source, machine-readable, contains all the data
+  \- **use this for editing**
+- [file-listing](
+  https://osegermany.gitlab.io/osh-dir-std/mod/designish/listing.txt)
+  \- like the output of `find` in a sample repo
+  \- generated
+- [tree](
+  https://osegermany.gitlab.io/osh-dir-std/mod/designish/tree.html)
+  \- like the output of `tree` in a sample repo
+  \- generated, **recommended** for inspection
+
+## Guiding principles & Inspirations
+
+This standard is inspired by design studio workflows and product development
+pipelines, where a contributor's first question is *"where are we in the
+process?"* rather than *"what file type is this?"*
+
+Key principles:
+
+- **Phase visibility**: Numbered top-level phases (`10_`, `20_`, `30_`) and
+  numbered sub-phases (`01_concept`, `02_design`, …) act as a visual
+  progress map.
+- **Designer-first**: No code background required — a designer naturally
+  moves from `01_concept` to `05_release`.
+- **Decision transparency**: Architecture Decision Records (`adr/`) are
+  first-class citizens, keeping design rationale visible to the community.
+- **Fabrication as a phase**: `03_make/fabrication_files/` separates
+  manufacture-ready exports from editable sources in `02_design/`.
+
+Some inspirations:
+
+- <https://www.designcouncil.org.uk/our-resources/the-double-diamond/>
+- <https://www.oshwa.org/sharing-best-practices/>
+
+## Structure Overview
+
+```mermaid
+graph TD
+    ROOT["my-osh-project/"]
+    ROOT --> LIC["LICENSES/"]
+    ROOT --> LICENSE["LICENSE"]
+    ROOT --> README["README.md"]
+    ROOT --> OKH["okh.toml"]
+    ROOT --> MGT["10_management/"]
+    ROOT --> LEG["20_legal/"]
+    ROOT --> ENG["30_engineering/"]
+
+    MGT --> MGT1["01_roadmap/"]
+    MGT --> MGT2["02_meetings/"]
+    MGT --> MGT3["03_stakeholders/"]
+    MGT --> MGTIN["input/"]
+    MGT --> MGTOUT["output/"]
+
+    LEG --> LEG1["licenses/"]
+    LEG --> LEG2["compliance/"]
+    LEG --> LEGIN["input/"]
+    LEG --> LEGOUT["output/"]
+
+    ENG --> ENGIN["input/"]
+    ENG --> ENGOUT["output/"]
+    ENG --> E01["01_concept/"]
+    ENG --> E02["02_design/"]
+    ENG --> E03["03_make/"]
+    ENG --> E04["04_validation/"]
+    ENG --> E05["05_release/"]
+
+    E01 --> E01A["requirements/"]
+    E01 --> E01B["moodboards/"]
+    E01 --> E01C["adr/"]
+
+    E02 --> E02A["electronics/"]
+    E02 --> E02B["mechanical/"]
+    E02 --> E02C["firmware/"]
+    E02 --> E02D["wear_parts/"]
+
+    E03 --> E03A["bom/"]
+    E03 --> E03B["assembly_guide/"]
+    E03 --> E03C["fabrication_files/"]
+    E03C --> E03C1["3d_print/"]
+    E03C --> E03C2["laser_cut/"]
+    E03C --> E03C3["pcb/"]
+
+    E04 --> E04A["safety/"]
+    E04 --> E04B["test_reports/"]
+
+    E05 --> E05A["oshwa_certification/"]
+    E05 --> E05B["media/"]
+
+    ROOT --> STW["40_stewardship/"]
+    ROOT --> USG["50_usage/"]
+
+    STW --> STW1["01_maintenance/"]
+    STW --> STW2["02_repair/"]
+    STW --> STW3["03_recovery/"]
+
+    USG --> USG1["example/"]
+
+    style ROOT fill:#f5f5f5,stroke:#999
+    style MGT fill:#dbeafe,stroke:#3b82f6
+    style LEG fill:#fef9c3,stroke:#eab308
+    style ENG fill:#dcfce7,stroke:#22c55e
+    style E01 fill:#eff6ff,stroke:#93c5fd
+    style E02 fill:#eff6ff,stroke:#93c5fd
+    style E03 fill:#eff6ff,stroke:#93c5fd
+    style E04 fill:#eff6ff,stroke:#93c5fd
+    style E05 fill:#eff6ff,stroke:#93c5fd
+    style MGTIN fill:#fde8e8,stroke:#f87171
+    style MGTOUT fill:#d1fae5,stroke:#34d399
+    style LEGIN fill:#fde8e8,stroke:#f87171
+    style LEGOUT fill:#d1fae5,stroke:#34d399
+    style ENGIN fill:#fde8e8,stroke:#f87171
+    style ENGOUT fill:#d1fae5,stroke:#34d399
+    style STW fill:#fef3c7,stroke:#f59e0b
+    style STW1 fill:#fef9c3,stroke:#fbbf24
+    style STW2 fill:#fef9c3,stroke:#fbbf24
+    style STW3 fill:#fef9c3,stroke:#fbbf24
+    style USG fill:#f3e8ff,stroke:#a855f7
+```