| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
All checks were successful
CI / markdown (push) Successful in 4s
Merge the selected feature/native-cli history with an explicit two-parent commit so main retains the development lineage and the validated source snapshot. The resulting tree is identical to the selected feature commit; no dependency pins or runtime behavior are changed by this merge. Previous main: |
||
| .github | ||
| .editorconfig | ||
| .gitignore | ||
| .markdownlint-cli2.yaml | ||
| ARCHITECTURE.md | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
| ROADMAP.md | ||
| rustfmt.toml | ||
| SECURITY.md | ||
EriX Meta Repository
This repository contains shared governance, contribution rules, and process documents for the EriX operating system project.
EriX is a clean-room, capability-based microkernel operating system written entirely in Rust.
All technical requirements are defined in:
- Requirements & Conventions Document
- Self-Hosting Milestones
See:
- docs for design documents, specifications, and development plans.
- Architecture repositories (kernel, bootloader, etc.)
Purpose of This Repository
This repository implements the EriX meta-governance repository. Its purpose in EriX is to define shared repository governance, contribution, review, and clean-room policy.
Functionally, it records organization-wide rules that component repositories follow. The repository keeps the implementation, interface contracts, tests, and documentation for that behavior in one reviewable ownership boundary.
The maintained responsibilities are:
- define shared contribution, review, licensing, and clean-room policy
- provide shared repository standards and governance material used across EriX
- keep project-wide process expectations independent of component code
- point every repository's contribution guide to the canonical permissive
generative AI policy in
docs, without requiring attribution trailers
Clean-Room Policy
EriX follows a strict clean-room philosophy:
- No external source code may be copied.
- No external Rust crates are allowed.
- No code generation tools that embed third-party code.
- All code must be authored within the project.
Violations will result in rejection of the contribution.
License
All EriX repositories are licensed under the ISC License.
Development Model
EriX development is:
- Modular (one repo per major component)
- Deterministic
- Reproducible
- Authority-explicit
- Security-first
- Self-hosting oriented
The non-normative planning archive is maintained separately. It does not define product APIs, runtime architecture, repository templates, or governance requirements.
Governance Principles
meta governance is scoped to shared repository standards and clean-room
contribution policy.
The scoped governance rules are:
- It defines organization-wide expectations without replacing component-specific implementation contracts.
- Shared governance and issue/PR templates remain byte-identical across repos; only component README, ARCHITECTURE and ROADMAP content is specialized.
- Contribution, licensing, and review policy must remain clear, auditable, and clean-room compatible.
- Generative AI assistance is permitted under the canonical policy in
docs; contributors retain complete responsibility and neitherSigned-off-bynorAssisted-byis mandatory. Cryptographic commit signatures remain required. - Project-wide policy changes require documented rationale before component repositories adopt them.
- CI runs
markdownlint-cli2across every Markdown policy, template, and workflow-support document in the repository.
Policy Boundaries
metaowns shared process policy; implementation policy stays with the component repositories.CONTRIBUTING.mdlists the canonical shared file set. Review changes here and propagate identical paths and contents to every repository, including new ones.- README, ARCHITECTURE and ROADMAP use shared formats with component-specific content; do not copy their placeholders into component documentation.
Contact
Development occurs in EriX organization and discussions happen in issues and design documents.
Discussions should occur via issues or design documents.
No decisions are considered valid without documented rationale.
You can also reach out to maintainers via email: admin@erikinkinen.fi.