47 lines
2.1 KiB
Markdown
47 lines
2.1 KiB
Markdown
# 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.
|