guidelining

README.md

@@ -15,3 +15,42 @@ Some pieces of software Null Linux attempts to modify _(under correct licensing)
 - A fork and stripped down version of [DASH Shell](https://wiki.archlinux.org/title/Dash)
 - A hand-rolled [DRM](https://en.wikipedia.org/wiki/Direct_Rendering_Manager) wrapper library.
 - Stripped Down version of the [runit](https://smarden.org/runit/) [init/PID1](https://en.wikipedia.org/wiki/Init)
+
+# Project Guidelines
+
+1. **C17, and only C17.** All Null Linux created or modified software will be in C17. If the project uses compiler-specific extensions, you must force a single C17-compatible compiler in the build system with no fallback.
+
+2. **Autotools or Makefile, nothing else.** All C projects can use either the GNU Autotools build system or a hand-created GNU Makefile. CMake, Meson, or any other build system is strictly not permitted.
+
+3. **AI drafts, humans ship.** The use of Artificial Intelligence IS permitted, but should be manually reviewed by living breathing _Homo sapiens sapiens_. AI work should be the **draft**, not the finished product.
+
+4. **Repository structure.** Every repository must follow a loose structure, but must remain similar to:
+
+```
+include/              Your headers. Headers do not mix with implementations.
+src/                  Said implementations.
+Makefile              Or configure.ac + Makefile.am (autogen.sh is required for autotools).
+bin/{release,debug}   Debugging should be in the workflow. Nothing is bug free. Release is
+                      ALWAYS -O2 or -O1, unless you give a damn good reason why it isn't.
+                      Examples include: compiler bugs, breaking optimizations.
+benchmarks/           You MUST benchmark your software. If it isn't memory-lean, it's not
+                      going in Null Linux. Benchmarks can be done any way, but should have
+                      a developer-eased abstraction. Examples: make bench.
+README.md             You should be introducing your software.
+docs/                 Very important. People should be able to know what your software is
+                      doing without looking at optimized C code.
+CONTRIBUTING.md       People should know how to help you.
+-STYLEGUIDE.md-       Optional.
+compile_commands.json Nobody likes their LSP. Nobody likes it more to be yelled at 24/7 for
+                      100% good code.
+.clangd               Who doesn't do this?
+.clang-format         Make your code look pretty for the love of christ.
+.clang-tidy           If nobody likes the LSP, everybody despises the linter.
+thirdparty/           If you use external libraries, you WILL be vendoring them. Dependency
+                      hell should not be a problem, and yet a 50 year old language still
+                      hasn't figured it out.
+```
+
+5. **Be very lean on RAM usage.** Null Linux is trying to minimize memory usage to the extreme, so nobody is benefitting from your "neat abstraction".
+
+6. **The kernel is yours. LibC is nice. A little TOO nice.** If it's small, if it's lean, you have ZERO reason to link with libC at ALL. Linux specific syscalls can do you well.