EriX C runtime and POSIX libc adapters using explicitly granted compatibility-service authority.
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-09-12 07:49:11 +02:00
.github Initial commit 2026-09-12 07:49:11 +02:00
.editorconfig Initial commit 2026-09-12 07:49:11 +02:00
.gitignore Initial commit 2026-09-12 07:49:11 +02:00
.markdownlint-cli2.yaml Initial commit 2026-09-12 07:49:11 +02:00
ARCHITECTURE.md Initial commit 2026-09-12 07:49:11 +02:00
CODE_OF_CONDUCT.md Initial commit 2026-09-12 07:49:11 +02:00
CONTRIBUTING.md Initial commit 2026-09-12 07:49:11 +02:00
LICENSE Initial commit 2026-09-12 07:49:11 +02:00
README.md Initial commit 2026-09-12 07:49:11 +02:00
ROADMAP.md Initial commit 2026-09-12 07:49:11 +02:00
rustfmt.toml Initial commit 2026-09-12 07:49:11 +02:00
SECURITY.md Initial commit 2026-09-12 07:49:11 +02:00

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 neither Signed-off-by nor Assisted-by is mandatory. Cryptographic commit signatures remain required.
  • Project-wide policy changes require documented rationale before component repositories adopt them.
  • CI runs markdownlint-cli2 across every Markdown policy, template, and workflow-support document in the repository.

Policy Boundaries

  • meta owns shared process policy; implementation policy stays with the component repositories.
  • CONTRIBUTING.md lists 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.