Publish Chimera GFX source

2026-09-03 03:27:14 +02:00
commit a6037502d7
828 changed files with 100454 additions and 0 deletions
@@ -0,0 +1,46 @@
+# Contributing
+
+All contributions must preserve the safety boundary in `SAFETY.md`.
+
+## Workflow
+
+1. Start from an issue or ADR-sized question.
+2. Update `RESEARCH.md` when a claim or source changes; label facts,
+   inferences, and unknowns.
+3. Add or update host tests before adding a backend behavior.
+4. Keep commits small: documentation/evidence, portable logic, and platform
+   behavior should be independently reviewable.
+5. Run the host build, full CTest suite, generated-file and manifest checks,
+   safety audit, format/static analysis, and secret scan.
+6. Do not add deployment commands or hardware execution to CI.
+7. Never weaken `execution_eligible`, remove a permanent denylist entry, or
+   bypass the Phase-0.5 minimal-startup configure failure.
+
+## Source requirements
+
+Use primary, public, open-source technical sources. Do not contribute
+proprietary SDK content, leaked or decrypted headers/binaries, exploit code,
+DRM bypass, direct register/MMIO access, firmware patches, or clock/SMU/fan
+control. ROMs, BIOS images, and copyrighted game content are outside scope.
+
+Guessed ABI declarations are not accepted. A symbol name is not a function
+signature. When evidence is incomplete, record an unknown instead of adding a
+plausible-looking definition.
+
+## Style and compatibility
+
+- C11, four-space indentation, no compiler extensions in the public API.
+- Public structures begin with `struct_size`; API changes require tests.
+- Destroy child handles before their context; cleanup failures must be visible.
+- Use SPDX identifiers in new source files.
+- Keep logs deterministic and free of addresses, credentials, user paths, and
+  content filenames.
+- Warnings are errors in project-owned code.
+
+## Hardware changes
+
+A pull request can prepare a disabled experiment, but review or merge does not
+authorize console execution. Each hardware test requires explicit approval in
+the active task and must follow the template in `TEST_PLAN.md`.
+Startup changes additionally require the exact loader-caller evidence listed
+in `docs/runtime/minimal-crt-feasibility.md` before an ELF may be built.