modified: DEVELOPMENT.md

Author: Tearran

DEVELOPMENT.md

@@ -1,4 +1,6 @@
-# Development Guide: configng-v2 Modules and Staging Workflow
+# Development Guide: armbian-config V3 (configng-v2)
+
+##  Modules and Staging Workflow
 
 This guide outlines the module development and assembly process for **configng-v2**.  
 It defines the current approach, philosophy, and workflow for Bash-based modules, with practical steps for contributors and maintainers.
@@ -8,7 +10,7 @@ It defines the current approach, philosophy, and workflow for Bash-based modules
 ## 1. Philosophy: Bash-Native Modularity
 
 - **Modules are Bash scripts** designed to run independently (CLI/test/demo) or be sourced by the main framework (TUI/automation).
-- **Config files** (`.conf`) use simple, flat key=value pairs—like classic Linux `.conf` or `.ini` files.
+- **Config files** (`.conf`) use simple, flat key=value pairs.
 - **No forced Pythonic patterns:**  
 	- Avoid unnecessary functions or complex/nested.
 	- Prefer simple, transparent Bash logic; use functions for clarity, not for forced structure.
@@ -21,49 +23,75 @@ It defines the current approach, philosophy, and workflow for Bash-based modules
 ## 2. Directory & File Structure
 
 - `staging/` — Where modules are created and refined before integration.
-- `src/` — Production modules (moved here after staging).
-- `testing/` — Manual and automated test scripts for modules.
-- `tools/` — Helper scripts for scaffolding, assembly, and automation.
+- `src/` — Production-ready source files (promoted from staging).
+- `tests/` — Manual and automated test scripts for both staged and promoted modules.
+- `lib/` — Consolidated, production-assembled Bash libraries (flattened from `src/`).
+- `tools/` — Scripts for scaffolding, promotion, consolidation, packaging, and workflow automation.
 
 Each module consists of:
 - `modulename.sh` — The Bash implementation.
 - `modulename.conf` — Configuration and registration info (flat, Bash/INI style).
-- `[optional] modulename_test.sh` — Test script for the module.
+- `[optional] test_modulename.sh` — Test script for the module.
 
 ---
 
-## 3. Staging & Module Workflow
+## 3. Module Workflow: From Staging to Package
+
+Each module follows a strict flow from creation to packaging:
 
 ### Step 1: Scaffold
 
-- Create a new module with:
-	```sh
-	./tools/staging_setup_scaffold.sh <modulename>
-	```
-- This generates:
-	- `staging/<modulename>.sh`
-	- `staging/<modulename>.conf`
+Create a new module scaffold:
+
+```sh
+./tools/staging_setup_scaffold.sh <modulename>
+```
+
+This generates:
+- `staging/<modulename>.sh`
+- `staging/<modulename>.conf`
+- (Optional) `staging/<modulename>_test.sh`
 
 ### Step 2: Develop
 
 - Implement logic in `.sh` with **tabs** for indentation.
-- Fill out all fields in `.conf` (see template below).
-- (Optional) Create associated test script in `staging/`.
+- Fill out all required fields in the `.conf` file.
+- Write a test `test_*.sh` script that targets the staging version.
+- (Optional) Extra info about module `doc_*.md` 
+
+### Step 3: Verify & Test
+
+- GitHub actions Runs `shellcheck`, formatting checks, and required field validation.
+- run `tools/staging_01_check_required.sh` to varify files requierd are met
+- Execute test script(s) in `staging/` to confirm correctness and compatibility.
 
-### Step 3: Submit
+##TODO
 
-- Commit and push both `.sh` and `.conf` (and test, if present) to the staging area.
-- Pull request triggers CI/workflow checks:
-	- Confirms all required files are present and `.conf` is valid.
+### Step 4: Promote
 
-### Step 4: Integration
+- Move module components to their target locations as defined in `.conf`:
+	- `.sh` → `src/<parent>/`
+	- `.conf` → `src/<parent>/`
+	- `.sh` test → `testing/`
+- This step makes the module part of the main tree and signals it's ready for assembly.
 
-- On successful checks:
-	- The `.conf` file is parsed for placement and registration (e.g., `placement=src/software/`).
-	- Module code and test scripts are moved to their respective directories.
-	- Central arrays/configs are updated for module discovery.
+### Step 5: Consolidate
 
-**Do not bypass this process or repurpose staging for other tasks—this ensures robust, repeatable integration.**
+- Flatten all `src/<parent>/*.sh` into a single `lib/<parent>.sh`.
+- This creates production-grade output files used by the main framework.
+
+### Step 6: Production Test
+
+- Run full framework tests using the consolidated scripts in `lib/`.
+- This ensures compatibility and functionality in their final state.
+
+### Step 7: Package
+
+- If production-test passes, package the tool (e.g., `.deb`) using the build system.
+- Output is stored in `build/` or `dist/`.
+
+**No steps should be skipped.  
+The workflow enforces modular clarity, testability, and maintainability.**
 
 ---
 
@@ -103,24 +131,28 @@ test_file=example_test.sh
 
 ## 6. FAQ & Rationale
 
+
 **Q: Why `.conf` and not `.meta` or `.json`?**  
 A: `.conf` is universally editable, Bash-native, and works with Linux tooling. No extra parsing or editor config needed.
 
 **Q: Can I use arrays or complex data?**  
 A: Stick to simple, flat config for maximum portability and ease of parsing in Bash.
 
 **Q: Must every module be a function library?**  
-A: No—modules should be as simple as possible. Use functions where helpful, but modules must be independently runnable.
+A: Bash doesn’t have “real” functions like other programming languages. In Bash, so-called functions are just named blocks of code:
 
 **Q: Why not a central controller?**  
 A: Independence makes modules more robust, easier to test, and more flexible for CLI, TUI, or automation.
 
+**Q: Are Bash functions meant for functional programming?**  
+**A:** No. They're meant for code structure and reuse—not abstraction or composition.
+
 ---
 
 ## 7. Path Forward
 
 - **Keep the workflow strict:**  
-	Staging, check, integration—no shortcuts.
+	Staging, promote, consolidate, production-test, package—no shortcuts.
 - **Keep modules independent:**  
 	Each must be testable and callable alone.
 - **Keep configs simple:**  
@@ -130,4 +162,4 @@ A: Independence makes modules more robust, easier to test, and more flexible for
 
 ---
 
-*Stick to these principles for a maintainable, robust, and Bash-appropriate modular system.*
+*Stick to these principles for a maintainable, robust, and Bash-appropriate modular system.*