Feature/contributing (#53)

* markdown updates

* tracking fixes

Author: lukeweston1234

.DS_Store

@@ -6,7 +6,7 @@ const { data } = await useAsyncData(() => {
 
 <template>
   <div class="w-full h-full flex justify-center">
-    <div class="max-w-200">
+    <div class="max-w-200 h-full overflow-auto">
       <article v-if="data" class="prose">
         <h1>{{ data.title }}</h1>
         <ContentRenderer :value="data"> </ContentRenderer>

docs/app/pages/contributing/index.vue

@@ -1,84 +1,56 @@
 ---
-title: Contributing
+title: Contribution Guidlines
 ---
 
-## Guidelines 
+## General Principles
+Before contributing, please understand the project's goals and community standards. Legato aims to help **humans** make art and run it on their own hardware.
 
-**Before working on any new functionality, please open an issue beforehand.**
+### AI Policy
+AI tools may be used for auxiliary tasks (e.g., generating test harnesses, proofreading, refactoring). However:
+* **Low-effort AI:** Pull requests that show clear signs of low-effort AI generation will not be accepted.
+* **Human-Centric Art:** The project **will not** incorporate or promote visuals, art, music, or other creative works that were not made by **humans** on official channels.
 
-Due to the plugin-oriented nature of Legato, it is unlikely that nodes will be added for every possible use case. However, if something is sufficiently general (e.g., pitch shifting, polyphase resampling), it may be considered.
+### Community & Licensing
+* **Code of Conduct:** We strive for a diverse, respectful community. Please see the *[Berlin Code of Conduct](https://berlincodeofconduct.org/en)* for general guidelines.
+* **Licensing:** Any contributions will fall under the license and additional permissions distributed with the repository.
+* **Logo Usage:** The Legato logo may only be used in non-monetized contexts (e.g., Matrix or Discord). Commercial packages or educational materials not adhering to AGPLv3 or fair use are not permitted.
 
-Any contributions will fall under the license and additional permissions distributed with the repository.
+## Getting Started
+**Before working on any new functionality, please open an issue.** Due to the plugin-oriented nature of Legato, it is unlikely that nodes will be added for every possible use case. However, if something is sufficiently general (e.g., pitch shifting, polyphase resampling), it will be considered.
 
-Lastly, I am to have a diverse, respectful community of people that just want to make cool things, and run it on their hardware. 
+### Development Setup
+Developers are strongly encouraged to use **Nix** to manage dependencies. This ensures benchmarks, configurations, and tests are reproducible.
+* **Standard Setup:** Clone the repository and use the provided Nix development shell (optionally via direnv). 
+* **Non-Nix Setup:** If you choose not to use Nix, you will need a **Rust nightly** toolchain. Note that contributions are still expected to build and run in the Nix environment.
 
-Please see the [Berlin Code of Conduct](https://berlincodeofconduct.org/en) for general guidelines of what is and is not acceptable.
+## Technical Standards
+Legato maintains strict requirements to ensure stability and real-time audio performance.
 
-## Development Setup
+### Code Style & Safety
+* **Modeling:** Prefer modeling state and events with `enums` or `bitflags`.
+* **Safety:** `unsafe` code with measurable performance gains is acceptable, provided safety is preferred elsewhere and Undefined Behavior (UB) is checked with **Miri**.
+* **Testing:** Non-trivial code should include at least a few relevant test cases and benchmarks using **Criterion** (with black-boxed inputs/outputs).
 
-Developers are strongly encouraged to use Nix to manage dependencies.
+### Real-Time & Concurrency
+Code that runs on the audio thread **must be wait/lock-free**.
+* **Prohibited:** Avoid mutexes, condition variables, syscalls, heap allocations, or any blocking synchronization primitives in the audio thread.
+* **Synchronization:** If using channels, queues, or ring buffers, they must be lock-free and non-blocking. Do not assume a standard channel is real-time safe without verification.
 
-This makes benchmarks, development configurations, and tests reproducible.
+### Performance Optimization
+When optimizing DSP code, follow these steps in order:
+1.  **Data Structures:** Use flat buffers or cache-optimized structures.
+2.  **Vectorization:** Use chunks_exact where possible for auto-vectorization. Consider polynomial approximations for operations that cannot be efficiently vectorized, or if the cost is too high.
+3.  **Branching:** Prefer branching at function entry rather than in hot DSP paths; use branchless solutions where appropriate.
+4.  **Memory:** Avoid heap allocations in hot paths; use arenas or preallocation if required.
+5.  **SIMD:** Once logic is optimized, consider std::simd(nightly) if it yields measurable gains.
 
-For now, this is as simple as cloning the repository and using the provided Nix development shell, optionally via `direnv`. While Nix is not required, contributions are expected to build and run in the Nix environment.
 
-If you do not wish to use Nix (fair enough), you will need a Rust nightly toolchain.
+## Pull Requests and Review
+All pull requests must adhere to the following checklist:
 
-## Code Style Guide
+* **Issue Reference:** Every PR must reference an existing issue, and the scope must match that issue.
+* **Validation:** All CI checks must pass. Non-trivial changes must include tests.
+* **Benchmarks:** Performance-relevant changes must include benchmarks or detailed justification.
+* **Documentation:** PRs should include a clear description of design decisions and trade-offs.
 
-* Prefer modeling state and events with enums or bitflags
-* Avoid locking primitives in real-time code
-* Avoid syscalls or heap allocations in the audio thread
-* Non-trivial nodes should include benchmarks using Criterion, with black-boxed inputs and outputs
-* unsafe with measurable performance gains is acceptable, but safety should be preferred under most circumstances, provided UB is checked with Miri.
-* Non-trivial code should include at least a few relevant test cases
-
-### Concurrency and Lock-Free Expectations
-
-Code that runs on the audio thread must be lock-free.
-
-Avoid mutexes, condition variables, and blocking synchronization primitives.
-
-If using channels, queues, or ring buffers, they must be lock-free and non-blocking under all expected conditions. Do not assume that a “channel” is suitable for real-time use without verifying its implementation.
-
-## General Performance Guidelines
-
-When optimizing DSP code, generally follow these steps:
-
-* Use flat buffers or cache-optimized data structures
-* Consider structuring algorithms to use `chunks_exact` where possible for auto-vectorization, if gains are observed when benchmarking
-* Prefer branching at function entry rather than in hot DSP paths.
-* Use branchless solutions where appropriate
-* Use polynomial approximations for operations that cannot be efficiently vectorized
-* Avoid heap allocations and system calls in hot paths; if allocation is required, use arenas or preallocation
-* Avoid mutexes or blocking primitives in audio-thread code
-* Once these steps are complete, consider `std::simd` (nightly) for further optimization, but make this yields measurable performance gains
-
-## Pull Requests and Review Process
-
-All pull requests must adhere to the following:
-
-* Every PR must reference an existing issue
-* The scope of the PR should match the associated issue
-* All CI checks must pass
-* Performance-relevant changes must include benchmarks or justification
-* Non-trivial changes must include appropriate tests
-* PRs should include a clear description of design decisions and trade-offs
-
-PRs that do not meet these requirements may be closed without review.
-
-## Logo Usage
-
-The Legato logo may only be used in non-monetized contexts.
-
-Community spaces such as Matrix or Discord are acceptable.
-
-Commercial packages of nodes or other educational material that do not adhere to AGPLv3 or are not fair use are not permitted.
-
-## AI Policy
-
-AI tools may be used for auxiliary tasks such as generating test harnesses, proofreading documentation, refactoring traits, or general review.
-
-However, pull requests that show clear signs of low-effort AI generation will not be accepted.
-
-Legato aims to help HUMANS make art. The project WILL NOT incorporate or promote visuals, art, music, or other creative works that were not made by HUMANS on official channels.
+*Note: PRs that do not meet these requirements may be closed without review.*