Systems / Tools within their boundaries
Make the working surface fit the work.
A shared keyboard and mouse across a desk. An offline file that carries its own interface and data. A permission map that shapes what a tool can do. Each starts with the environment the person actually works in.
The OS topology explains the setup pictured on the homepage. The software and permission examples are synthetic and labeled where they appear. All diagrams are readable without JavaScript or motion.
01 / OS layer
One desk, distinct control paths.
I designed and work through a custom OS layer, EsotericOS, with unified keybindings across macOS, Windows 10, Windows 11 and iPadOS. The homepage’s desk brings those paths into one view.
Installed where it can be
The OS layer installs on machines where installation is available. Its desk view brings screen arrangement, keybindings and cabling into the working surface.
Paired input where it cannot
On the managed computers and iPad pictured, the other end is a codeless Bluetooth keyboard-and-mouse pair. Pairing supplies input; the person watches the screen and directs the work. This path does not establish access to files, administrative control or permission to install software.
- Built-in Bluetooth → audioHeadsetThe hub’s built-in radio carries headset audio.
- Radio 2 → Bluetooth inputManaged Mac · macOSA paired keyboard-and-mouse endpoint.
- Radio 3 → Bluetooth inputManaged MacBook · macOSA separate paired input path.
- Wi-Fi → controlWindows 11 laptopIts Bluetooth radio is split between input to the managed iPad and audio to a headset.
Input, audio and Wi-Fi control are different paths. This is an explanation of the pictured arrangement, not a compatibility or reliability guarantee for another device or radio combination.
How profiles relate the desk to the screens
Two profile layers describe the desk’s physical arrangement and each monitor’s specifications. Each desk also carries a cabling profile that swaps automatically with what is connected; a physical switch retargets it in real time. In the homepage illustration, switched screens change between the managed Mac and the Windows 10 laptop.
The drawing distinguishes which machine owns a screen from the input path used to work on it. A paired input connection alone does not imply that the OS layer can inspect the receiving device’s data.
02 / Constraints
Let the permission boundary shape the tool.
The Envelope demonstration makes a managed-browser policy visible: inspect the permission set, apply the policy, then distinguish blocked and unset entries before choosing an implementation.
- 41 listed permissionsThe demo begins with its full illustrative inventory.
- 18 blockedApplying the simulated policy marks the blocked entries and leaves 23 in the demo’s working set.
- 9 marked unsetThe Unset filter highlights a subset of those 23. Unset does not mean approved.
| Demo status | Example permissions | Decision boundary |
|---|---|---|
| Retained | activeTab, scripting, storage | The demo leaves these in its working set; it does not grant them on a real device. |
| Blocked | downloads, nativeMessaging, debugger | Do not design the shown workflow around these capabilities under this policy. |
| Unset | sidePanel, readingList, tabGroups | Resolve the applicable policy and approval before relying on them. |
The homepage’s policy.json button applies a fixture. It does not inspect a visitor’s device or import a real policy export. These counts describe the demonstration only.
What the envelope does and does not decide
A permission map helps define the design space. It does not authorize an extension, grant a browser permission, or override a device’s management controls. A local file and an extension also have different capabilities; the offline-file pattern below is not a promise that every browser permits the same workflow.
03 / Offline tools
The file is the application.
I build self-contained HTML, CSS and JavaScript applications, Chrome extensions with Manifest V3, Python build pipelines and VBA automation. The offline-file story shows how an interface, data and a handoff can travel together.
- 01 / Open the fileOne HTML file contains the interface, embedded data and in-browser spreadsheet parser.
- 02 / Work and autosaveEdits are saved locally in the browser using IndexedDB.
- 03 / Save a copyThe application writes a copy with the current data baked into its HTML.
- 04 / Hand off the copyThe saved file carries the application and its embedded state for the recipient to open. This illustrated pattern has no server.
Browser autosave and a saved HTML copy are separate states. The copy carries the data embedded when it was saved; later edits in the first browser are not a live update to that copy.
Why the save boundary matters
Autosave keeps work in the browser. Saving a copy makes an explicit handoff artifact. The recipient needs that updated copy, not an assumption that local browser storage follows a file. The lifecycle explains the software pattern; it does not claim measured time savings or universal browser support.
Career context / The daily operating dashboard
I conceived and built the site’s daily operating dashboard: an offline application synthesizing raw workforce and performance data into one operating system, used daily by ~50 supervisors and managers.
The analytical tools shared a roster backbone and a weekly ETL pipeline over SAP BusinessObjects and Superset, replacing manual reporting across attendance, adherence, quality, coaching, staffing and cost.
That adoption figure comes from the career record on the homepage. The file lifecycle above is an illustrative explanation, not a production screenshot or a measured outcome.
04 / The Forge
The development environment in the chain.
The homepage labels the Forge as “my IDE” and places it between the OS layer and the work dashboard.
OS layerThe Forge · my IDEThe work dashboard
That label gives the development environment its place in the workflow. The operational evidence is the tool, its data boundary and how people use it.