Versioned School-GIT OS
The CDN desktop shell is now treated as a versioned software release with immutable runtime files instead of a permanently live source tree.
System flow
Edit source
Build compiled OS runtime
Publish immutable release
Install version slot
Restart
Activate or rollback
Source map
- components/cdn/os/SchoolGitOsBootstrap.tsx
- components/cdn/os/SchoolGitOsRuntime.tsx
- components/cdn/os-runtime-entry.tsx
- lib/cdn/os/client-os-bootstrap.ts
- lib/cdn/os/client-os-updater.ts
Architecture diagram
mermaidflowchart LR
Source[Desktop / WindowManager / Cursor / CSS] --> Build[OS build]
Build --> Release[Immutable OS release]
Release --> Install[OPFS version slot]
Install --> Pending[pending-version]
Pending --> Boot[Stable bootstrap]
Boot -->|ready| Active[active-version]
Boot -->|fail| Rollback[previous-version]What belongs to the OS
Desktop.tsx, WindowManager.tsx, CustomCursor.tsx, taskbar/start UI, system settings, built-in system applications and other shared browser-side shell code are OS components when they are part of the compiled OS runtime.
An edit to one of those files is not automatically a published OS update. It becomes an OS update only after a new immutable release is built and distributed.
Stable bootstrap boundary
The bootstrap itself is intentionally small and stable. It selects which installed OS release should run, verifies the selected slot, loads the versioned CSS and JavaScript runtime, then waits for the OS runtime to signal readiness.
This separates the loader from the software it loads. A broken new desktop bundle can therefore fail without destroying the previous working version.
Development remains fast
Next.js development HMR is still useful while building the next release. The release boundary is about what installed users boot, not about making development intentionally slow.