The Cockpit Triad: Private Deep-Drill, Public Limited, and Chat Host

I was trying to make one surface do too many things. Once I mapped the architecture, the problem was obvious.

The mistake was conflating three distinct roles: where I work, what I share, and how I talk to agents. Trying to serve all three from a single surface was making each one worse. The fix was a clean split into three legs, each optimized for its primary user.

Leg one: the private cockpit

The first leg is the private deep-drill environment. For me, this is a tailnet-only web cockpit that runs on my own machine and never reaches the public internet. It holds my focus dashboard, a direct viewer into my markdown vault, and the raw operational data I need to run my agent team.

This surface is unpolished by design. It is dense, fast, and built entirely for my own operational speed. I do not share URLs from it. It does not have user authentication, because I am the only user. The DNS resolves to a non-routable tailnet IP. Nothing about it is built for external eyes, which means nothing about it is compromised by the need to look good.

This is where I do the actual work. Drilling into session manifests, reading raw logs, checking agent output before it gets pushed anywhere public. The private cockpit is the messy reality of the vault made navigable.

Leg two: the public limited surfaces

The second leg is where polish matters. It is divided into two parts.

The commercial side is dxdev.com. This is where I publish technical posts and marketing content. Everything that lands here has been through the publishing pipeline: drafted in the vault, reviewed, and pushed outward across the boundary. It signals credibility to prospects and documents the system for a public audience.

The personal side is the notes app, which acts as a public gateway for a different kind of output. Both surfaces are careful and curated. They show the results of the work, not the messy reality behind it.

The key constraint is that these surfaces never reach inward. The public internet does not get a path back into the vault or the private cockpit. Data flows outward only.

Leg three: the chat host

The third leg is the interactive layer where I actually talk to agents. Right now, I use Cursor for this. The planned evolution is Personal Command, a single-user tool that reads from the vault and connects to live channels. It is not public-facing. It is the interface between me and the agent team.

The chat host is distinct from the private cockpit because it is conversational rather than operational. The cockpit is for reading and drilling. The chat host is for directing.

Why the split matters

The mistake I was making was trying to build sharing features into the private cockpit. I wanted the deep-drill views to look good enough for external eyes. But that compromises both goals. A surface built for public consumption will never be dense enough for real operational work. And a surface built for deep-drill operations will always expose too much context for a public audience.

By splitting them, each surface optimizes for its primary user. The private cockpit stays ugly and fast. The public surfaces focus on narrative and polish. When I generate a visual map of my system, I now know it needs two versions. The public version goes to dxdev.com. The deep-drill version stays in the private cockpit.

This separation also clarifies the publishing pipeline. Blog drafts start in the private vault. They are reviewed and refined there. When they are ready, they are pushed across the boundary to dxdev.com.

When I generate a visual map of my own system now, I know it needs two versions. The public version goes to dxdev.com. The deep-drill version, the one dense enough to actually work from, stays on the tailnet-only cockpit and never crosses out.

dxdev LESSON · paste into your AI coding agent
LESSON: A surface trying to serve both a private operator and a public audience will compromise both jobs
SOURCE: dxdev.com/blog/2026-05-10_cockpit-triad
WHAT HAPPENED: A single dashboard was being pulled toward two incompatible goals: dense operational speed for personal use, and enough polish to be safely shown to external eyes, and trying to serve both was making each one worse. The fix split the system into three distinct legs by role: a private, unpolished, tailnet-only operational cockpit for deep-drill work; public, curated, one-way-outbound surfaces for external audiences; and a separate conversational interface for directing agents, with data flowing outward from private to public but never back inward.
THE RULE: When one surface is being asked to serve both an internal operator's deep-drill needs and an external audience's polished expectations, split it by role rather than trying to make one surface satisfy both, and keep private-to-public data flow strictly one-directional.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any internal or operational dashboard or tool with features added specifically to make it presentable to external viewers, at the expense of operational density or speed.
  2. Any public-facing surface with a data path or link that could resolve back into private or internal infrastructure, rather than flowing strictly outward.
  3. Any single tool or view conflating more than one of: private operational work, public-facing publishing, and interactive agent direction, without a clear boundary between them.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.