Files
Chimera GFX release export a6037502d7
phase0-ci / build-and-audit (push) Successful in 2m14s
Publish Chimera GFX source
2026-09-03 03:27:14 +02:00

2.1 KiB

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.