Technical
Appendix

Pulite is organized as cooperating browser layers rather than a single monolithic scene. Each layer owns a stable responsibility and exposes deliberate entry points to the next.

A route can initialize its own surface without owning the global shell. An application can request shared behavior without reconstructing the surrounding environment. Storage domains can evolve without turning every boot into an undocumented cleanup pass.

Navigation is coordinated with browser history, and route-level modules initialize the sections they own. This preserves normal URL behavior while allowing transitions and return state to participate in the experience.

The DOM is used directly where timing, composition, accessibility, and fine-grained visual control matter. Vanilla JavaScript and CSS keep that relationship explicit. External tooling supports the build, testing, and selected visual capabilities; it does not replace the browser as the primary execution model.

PuliteOS is implemented with standard browser capabilities including the DOM, storage APIs, media elements, history, and pointer and keyboard events. It brings a window and desktop shell, applications, files, messaging, preferences, and recoverable workspace state under one interface.

Applications receive a bounded service interface instead of importing every system manager independently. This reduces coupling and gives cross-application behavior a stable place to evolve. Compatibility helpers remain where older modules still need them, while new work can target the shared boundary.

The result is a coherent device surface whose parts can be entered independently while remaining part of the same session.

The PuliteOS kernel is the runtime authority for boot policy, system processes, resource ownership, mounted VFS roots, and status reporting. It does not render the shell or implement every subsystem itself. It establishes the lifecycle and shared contracts through which those subsystems cooperate.

The kernel owns the process and resource registries and receives the virtual file system as a mounted subsystem. During initialization, the host constructs the runtime service boundary; kernel boot then hydrates system records, establishes coordination policy, activates kernel-owned services, and publishes an observable status snapshot. Shutdown reverses that lifecycle by tearing down event bridges, releasing owned resources, and clearing runtime records when requested.

Applications receive bounded capabilities for windows, files, direct manipulation, keyboard input, shell behavior, messaging, processes, resources, and filesystem access. Terminal reads kernel status, uptime, mounted paths, the boot sequence, and the published service manifest. Task Manager reads the same registries and requests restoration or termination through that shared boundary.

A pointer gesture may begin on the desktop, cross a window, pass over a sidebar, and end inside an application. PuliteOS gives that journey one coherent account of what will happen.

1. Session
2. Detection
3. Policy
4. Validation
5. Feedback
6. Execution
7. Persistence
8. Refresh

The session normalizes the object or group being manipulated. Detection follows visible stacking order while reading current geometry. Policy translates the destination into an action. Validation checks the complete operation before mutation. Feedback communicates the same decision execution will use. Persistence records the result, and affected surfaces refresh once after the operation.

Applications can opt into the same drop protocol by describing whether they accept an object and then handling the committed operation. Files can cross application boundaries without moving app-specific logic into the desktop.

Pulite follows a local-first persistence model for its core continuity. Small flags, preferences, layout metadata, and file-tree state use local storage. Larger or structured user content uses IndexedDB-backed stores where appropriate.

The site shell and PuliteOS are delivered from the same origin, and their persisted state is declared in one domain registry.

The migration entry point runs before normal experience initialization, so tracked keys and declared domain versions are reconciled before either surface relies on them.

This is an engineering consequence of presenting the environment as personal. If a user can name, write, arrange, or leave something behind, routine updates should not silently discard it.

Local continuity remains tied to the browser profile and device where it was created. Clearing site data, using a separate profile, or moving to another device does not automatically transfer that state.

Pulite combines ordinary document rendering with media and procedural surfaces. Its performance model is based on activation rather than permanent simulation.

• Route and application code can be loaded when its surface is needed.
• Inactive application state does not require continuous background execution.
• Large editable content stays outside small synchronous storage paths.
• Diagnostic collections remain bounded.
• Media and expensive visual work follow visible or explicit activity.
• Reduced-motion preferences remain part of public document behavior.

Production uses a minified Vite build and a controlled static-asset copy step. Source maps are not emitted. The result remains a conventional web bundle that can be served by standard static infrastructure.

Pulite treats code and assets delivered to the browser as publicly inspectable. Client bundles are not used to hold credentials, private keys, hidden administrative controls, or sensitive configuration.

Core continuity is stored locally, reducing the need for an account merely to remember a visit. Local storage is persistence, not a secure vault: data in a user's browser can be viewed, exported, changed, or cleared by that user.

User-supplied labels and text that enter HTML templates pass through shared escaping boundaries. Networked features are expected to send only the data required for their stated operation and to handle unavailable connections without damaging local state.

Pulite targets modern browsers. Media support, storage quota, graphics performance, font rendering, and autoplay behavior can vary by browser, device, and user setting.

These constraints are part of the architecture, not exceptions to it.

1. 01Keep the site itself addressable and enterable.
2. 02Preserve user-owned state through explicit migrations.
3. 03Keep authored surfaces separate from shared runtime responsibilities.
4. 04Load expensive behavior in proportion to visible use.
5. 05Treat public client code as public material.
6. 06Keep network exchange narrow and recoverable.
7. 07Test production behavior at the same URLs people will visit.
8. 08Describe capabilities precisely without turning authored discovery into documentation.

Pulite is built as a continuous web work. Documents, authored scenes, applications, and personal state share one addressable system without being flattened into a single rendering model. The public site remains legible as a site; PuliteOS provides a coherent workspace; local persistence lets the environment remember what a visitor changes.

That coherence comes from shared rules: windows resolve against the current workspace; gestures are validated before mutation; applications enter through registries and bounded services; file identity survives movement; expensive work follows visible activity; and user-owned state has an explicit lifecycle. Each surface may have a different voice while remaining part of the same architecture.

Pulite treats the browser as the medium and accepts the responsibilities that follow. Its technical standard is the quality of each supported action: immediate, intelligible, recoverable, and continuous with the whole. Desktop conventions are adopted where they strengthen those qualities.

The architecture exists to protect that continuity. It gives authored work room to remain strange, documents room to remain readable, applications room to become capable, and the visitor's actions enough permanence to matter. Implementations can change; these properties should not.