#Part 9. Compiler And Package Formats

#Part 9 Section 1. Build Pipeline

The normal path is source, check, package, runtime validation, and target export:

.cbp source -> parser/checker -> package manifest -> .cba -> target host/export

check should run before every release compile. A successful parse is not enough: the checker must resolve functions, verify arguments, validate types, and reject incompatible flags. Build scripts should stop on the first nonzero exit code.

#Part 9 Section 2. What Each Output Means

- .cba is the canonical ClosedBit application package consumed by the Runtime. - .cbl is a reusable ClosedBit library package, not a standalone app. - .exe is a Windows launcher/export containing or locating the packaged app and required native runtime pieces. - .dll is for a supported host boundary; it is not a general promise of C ABI compatibility. - Linux beta output is a package folder and must be tested on the actual distribution and architecture. - Kernel targets are freestanding outputs with a much smaller supported surface than desktop apps.

Never rename one format to another and call it converted. The compiler must emit the target because manifests, entry points, integrity fields, and runtime assumptions differ.

#Part 9 Section 3. Reproducible Builds

A release build record should contain the ClosedBit version, source commit or source digest, compiler arguments, architecture, dependency versions, asset digest, build timestamp, test results, and signing identity. Keep generated output out of the source folders unless a build script intentionally stages it.

Release packages should be rebuilt from a clean staging directory. A build that succeeds only because an old DLL is nearby is not reproducible.

#Part 9 Section 4. Kernel Targets

Kernel work uses freestanding compiler targets rather than the desktop Runtime. The current tree includes native kernel checks for x86 and ARM64 work. Kernel code cannot assume desktop file APIs, HTML UI, Windows DPAPI, managed networking, or a process host.

Keep the layers explicit:

firmware entry -> architecture bootstrap -> memory/interrupt core -> device drivers
               -> scheduler/process model -> filesystems/networking -> user space

Passing a boot smoke test means the bootstrap worked. It does not establish memory safety, hardware compatibility, driver coverage, storage durability, or release readiness.