orlix-implementation-boundaries

Use before implementing or triaging Orlix changes when ownership could involve OrlixOS, OrlixKernel, OrlixMLibC, OrlixCoreUtils, OrlixMachine, Containers, Herdr, OrlixTCTI, OrlixHostAdapter, the native Orlix app, upstream Linux, upstream mlibc, packages, product payloads, session APIs, or generated trees. Routes fixes to the correct layer and blocks wrong-layer shortcuts.

Jump to install

Repository: rudironsoni/Orlix
Last source activity: July 26, 2026 at 17:30
Detected SKILL.md language: English
Stars: 0
Forks: 0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/rudironsoni/Orlix --skill orlix-implementation-boundaries

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

Orlix Implementation Boundaries

Use this skill before changing code for non-trivial Orlix behavior, especially kernel/libc/package/runtime issues.

Routing

Linux semantics: OrlixKernel/Sources/ports/orlix, upstream Linux overlay paths, Linux-native drivers, boot, KUnit, or kselftest.

Libc behavior: OrlixMLibC/Sources and OrlixMLibC/Tests.

Core userspace utilities: private OrlixCoreUtils, using normal Linux process and libc behavior.

Public delivered OS Kit, app-facing API, target-derived payload metadata, curated distribution policy, and package/rootfs assembly: OrlixOS.

Linux machine and session composition behind the public Kit: OrlixMachine.

Container lifecycle and machine integration: Containers.

Terminal Session, Workspace, Tab, Pane, focus, and topology: Herdr.

Guest instruction translation and execution beneath Linux: OrlixTCTI.

Private Apple and Darwin execution mechanics: OrlixHostAdapter/Sources.

iOS and iPadOS application UI and presentation of Herdr-owned terminal state: the native Orlix application source compiled directly into the production app target.

Architecture truth: typed decision, component, capability, and concept pages reachable from docs/index.md.

Refusals

Do not:

edit generated upstream trees or disposable build output; reading generated trees for diagnosis is allowed;

add or change durable upstream patches before proving the lower owning layer is compliant and the patch is not hiding an OrlixKernel, OrlixOS, or toolchain mismatch;

modify upstream tests through durable patch stacks used by conformance schemes; move extra regressions to Orlix-owned tests;

move Linux policy into OrlixHostAdapter;

move guest instruction decoding into OrlixHostAdapter;

move libc behavior into OrlixKernel;

move syscall semantics into OrlixOS;

recreate a separate OrlixKit target/module; OrlixOS is the Kit;

expose private OrlixKernel, OrlixMLibC, or OrlixCoreUtils as parallel app-facing APIs;

duplicate Herdr's Session, Workspace, Tab, Pane, focus, or topology state in the native app or another Orlix layer;

move terminal topology into OrlixOS, OrlixMachine, or Containers;

create a reusable OrlixTerminal framework or generic product boundary around the native Orlix application;

restore the retired UIKit terminal controller, its separate diagnostic app target, or its conflicting Ghostty package;

hardcode product bundle identifiers or payload resource names in runtime code when they belong in project.yml or target metadata;

disable upstream package capabilities or invent package-specific linker/tool wrappers instead of fixing OrlixOS package-toolchain inputs;

add public runtime facades or shell/package management APIs;

restore retired local-kernel prototype paths.

Output

Before implementation, state the owning layer, why that layer owns the behavior, the files to inspect first, and the verification gate.