Dev Center Project Vision

🛰️ The DOS Vision

DevCentr is an organization dedicated to fundamentally improving developer productivity and workflow for pure human development and human-in-the-loop AI vibe-coding.

Our flagship project, DevCentr, is a Development Orchestration Suite (DOS)—a platform sitting a layer above the code to manage the complexity of the modern developer’s world. By treating development as an integrated ecosystem rather than just a series of text files, DevCentr provides an integrated workspace and infrastructure environment designed for the future of engineering.

The public category is DOS. A casual mental model is Dev OS (orchestration of the environment around development)—useful for association, not for marketing headlines. DevOps is one facet of the suite: CI/CD, infrastructure, and traditional ops where they sit on the path. We allude to DevOps in literature to widen that concept over time; we do not brand the whole product as a DevOps GUI.

While traditional IDEs focus on the editor, DevCentr focuses on the Orchestration of the entire development lifecycle:

  • Ecosystem Management: Author and version your entire environment—shells, toolchains, and infrastructure—as first-class citizens. For shells, we standardize on Nushell across Windows, macOS, and Linux (structured pipelines; see Why We Recommend Nushell). For toolchains, we endorse Toolchain Management: the ecosystem’s main entrypoint must own install, version pinning, health, repair, and upgrade—shipping a Toolchain Control Plane rather than leaving newcomers to discover tribal version managers.

  • Visual DevEx: A "Live Blueprint" approach that visually models project architecture, moving beyond simple file trees into system design.

  • AI Vibe-Coding Synergy: A hub that provides the deep contextual metadata necessary for human-in-the-loop AI coding to be truly effective.

  • Literate Programming First: Promoting an architecture where documentation is the primary source, and code is an extracted artifact. We endorse Synchronous Literate Programming (SLP) to eliminate the gap between narrative and execution.

  • DevOps (one facet): Pipelines, infrastructure, and delivery ops as part of the path—not the definition of the product.

It should help new developers and experienced developers set up a new machine for development purposes and provide in depth information about any actions it performs, the environmental changes it makes, and the purposes of the tools it installs.

Literate Systems Strategy

In Dev-Centr, any doc about a language—such as C or D—mentions literate programming immediately after its introduction. This ensures that devs instill the habit of using literate systems from the start of their engagement with a technology. We favor CentrMark for native SLP support but provide guidance for Quarto and Entangled for CommonMark users.

Management Tool Hierarchy (Abstract)

This diagram shows the "what controls what" hierarchy of management roles, reflecting the ideal way to manage development environments.

In a mature ecosystem, version management is not a side tool the user must find—it is part of the main toolchain entrypoint (or a thin official shim that is what you install). Community version managers are a bridge when the official entrypoint still lacks that capability. See Toolchain Management Pattern.

graph TD
    SYS["System Package Manager (e.g. winget, brew)"] --> TCP["Toolchain Control Plane / official entrypoint"]
    TCP --> VM["Version resolve and pin (first-party; community VM as bridge)"]
    VM --> RT["Language Runtime (e.g. Node.js, Flutter SDK)"]
    RT --> WRAP["Manager Wrapper (e.g. Corepack)"]
    RT --> NPM["Bundled Manager (e.g. npm)"]
    WRAP --> PM["External Package Manager (e.g. pnpm, yarn, Bun)"]
    PM --> DEP["Project Dependencies (Libraries)"]
    NPM --> DEP
    DEP --> APP["Application Codebase"]
    SYS --> B_RT["Independent Runtime/PM (e.g. Bun)"]
    B_RT --> DEP
    TCP --> HEALTH["Health, repair, upgrade, rollback"]
    ORO_NOTE["Orogene: closed-aspirational north star"] -.-> PM

Management Tool Hierarchy (Specific)

This diagram shows the specific tools used and suggested in this ecosystem.

graph TD
    W["UniGetUI / winget"] --> NVM["nvm-windows"]
    NVM --> NODE["Node.js"]
    NODE --> CP["Corepack (Bundled)"]
    NODE --> NPM["npm (Bundled)"]
    CP --> PNPM["pnpm"]
    CP --> YARN["yarn"]
    W --> BUN["Bun"]
    PNPM --> NEXT["Next.js Framework"]
    YARN --> NEXT
    BUN --> NEXT
    NPM --> NEXT
    NEXT --> LIBS["Libraries / React"]
    LIBS --> APP["Project Components"]
    ORO["Orogene (closed-aspirational)"] -.-> BUN
    ORO -.-> PNPM

Package-manager policy (pnpm preferred, Bun as practical OSS alternative, Orogene as once-and-future inspiration): npm package managers.

The app should contain models or diagrams of the different facets of software project management:

  • User (machine) environment

    • PATH variables

    • shells

    • Container apps available (Docker, podman)

    • Container images available (with icon from common logo api)

  • Project paths (with button to add a new path to the manager). This would be a path to a folder containing project folders, not to the individual projects.

    • Projects

These diagrams should be 2-dimensional and pannable using middle-click-drag or touch pad. The elements should be iconified with label to the right, organized hierarchically, with the environment to the left of the projects it contains, and with its properties (PATHs, shells, etc) in report format in a box under the user environment label, with a "PATH vars" section and "user" and "system" buttons to edit the PATH variables. The Project Path nodes should be icon + label to the right, with a list of project folders indented to denote child-parent relationship. The list of project folders should be in its own block on screen. Each project should have an icon + label to the right. The icon will be a generic project icon, optionally replaced by a specific technology icon depending on if that project is exclusively one type of project.

Double-clicking a project in the diagram

Each project should be modeled/diagrammed:

  • Environments

    • Default environment if none are defined (labeled "default blank")

    • Dependency isolation mechanisms:

      • Virtual environments using common environment configs (venv, pyenv, virtualenv, pipenv, Poetry, conda)

      • Node.js modules specification (not treated as an environment but as 'inside' an environment, such as a blank environment)

    • .env variables as semi-environments (.env* pattern, excluding .env*.example pattern)

    • Documented build environments, such as dev,

  • Internals of the software project

    • Project structure

      • Technologies used

      • Paths

    • Virtual environments

  • CI/CD configuration

  • Diagram nodes should be interactive and allow users to drill down into the details of each component. If a component is sufficiently complex, open the component in a new window in the diagram renderer (not a new native window).

Essential Functions

Project Management

  • Manage local software projects

  • Connect to arbitrary code repositories

  • Connect to major repository services' user accounts and discover projects, including the following:

    • GitHub

    • GitLab

    • GitLab self-hosted instances

    • Gitea

    • AWS code-commit

    • Bitbucket

    • other git repos

    • SourceForge accounts

    • other mercurial repos

    • SVN

    • Perforce (if possible)

    • TFVC

    • Azure DevOps accounts

    • CVS repos

It needs to store each of these services' functions in definition files that can be updated and extended instead of hard-coding the functionality. I also know that these account services do not conform to a standard API definition for discovery of account assets, so please propose a standard for these version control services to conform to in a new asciidoc file that includes methods for user assets, organization assets, repository assets, CI/CD assets, and anything else that seems relevant. Also create an openAPI specification and link to it or its sections where relevant in the asciidoc files. The app will need to be able to identify and download a universal configuration file in an appropriate format from each repository that tells it how the project is configured (in TOML or YAML).

Look at the Repository provider registry.adoc file for a specification for how to keep track of repository providers.

Virtual Environments

needs to support recognizing virtual environments and virtual machines. mounting, managing, and viewing them in the project management interface. user should be able to mount and manage them from the diagram. if the tool is missing to do so, offer to install it. If the tool’s management capabilities are significantly complicated, outsource the management of complex settings to the application.

the project viewer must show various types of models/diagrams of the project architecture. Dependency tree/graph is required. Control tree/graph is required. For cases like Next.js, which relies on React but controls React’s usage, dependency doesn’t communicate the whole picture. The control tree will differ from the dependency tree in cases like this.

For each language ecosystem, prefer an official Toolchain Control Plane when one exists (unifiedControlPlane.status = official in the language definition)—that is the product of the Toolchain Management Pattern. When the ecosystem still lacks one, DevCentr:

  1. Shows a short advisory at the top of that ecosystem’s management module (link to the Toolchain Management Pattern).

  2. Offers the top community version managers as a bridge so the user can still pin safely.

  3. Lets the user choose again per new project when multiple bridges exist.

Do not treat “pick among three community VMs” as the end state—encourage maintainers to absorb pinning into the main entrypoint (optionally via the Toolchain Framework (TCF)).

ecosystems to target:

  • Web

  • System languages

  • Mobile / multi-platform (e.g. Flutter) as a control-plane case study

SSH Key Management

Include a SSH key and config manager with helpful dialogs to onboard the user, explain the purpose of SSH keys (and explain why they need to use ed25519) and how to name and store them (name the key after the service and username or email address), recommend using a new key for each service and explain why, assist with setting up ssh config entries for SSH keys and explain the file and let the user edit it in the config dialog, run, show, and return results of the ssh-keygen command during creation of ssh keys, set up ssh-agent for the user while being explicit about it, set up the user’s shell profiles to load the user-agent on launch.

Tool Integration

The main project management UI will be able to launch specialized tools and other 3rd party tools like VScode, Cursor, etc.

GUI modules that interact with services should pull each service configuration information from a service definition file. User specific information is separate from the service definition.

User configuration information gets stored in %USERPROFILE%\Dev Center

Environment Navigator

The app needs an environment navigator that models the environment hierarchy/nesting/containment (for example these levels would be discovered: Hardware → Hypervisor (or Bare Metal OS) → Virtual Machine OS → Container / App Environment) using cpuid instruction checks and an environment browser that opens up when the user selects an environment from the main environment navigator. The nested environment hierarchy needs to be modeled. The environment browser helps with identifying where settings files are stored and explains the various locations and environment variables of the system. System and user environment variables need to be browsable and editable, with a special interface for editing the PATH variables. Individual app environment variables

UI Specification & Roadmap

Visual Paradigm

The Dev-Center application prioritizes a premium, high-fidelity user interface. Current UI implementation uses the dlangui library.

Logical vs Optical Pixels

At present, the underlying UI library (dlangui) does not natively differentiate between logical and optical pixels for all widget measurements. All specifications in this document and the development roadmap assume a transition toward logical pixel support.

  • Tool Icons: Every tool in the dashboard must be displayed with an icon against a fixed-size background of 200x200 logical pixels.

  • Roadmap: Future versions of the Dev-Center app will implement a DPI-aware scaling layer to ensure consistent sizing across high-density displays (Retina/4K), standardizing all layout measurements to logical pixels.