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.

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.

  • 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.

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.

graph TD
    SYS["System Package Manager (e.g. winget, brew)"] --> VM["Version Manager (e.g. nvm, asdf)"]
    VM --> RT["Language Runtime (e.g. Node.js)"]
    RT --> WRAP["Manager Wrapper (e.g. Corepack)"]
    RT --> NPM["Bundled Manager (e.g. npm)"]
    WRAP --> PM["External Package Manager (e.g. pnpm, yarn)"]
    PM --> DEP["Project Dependencies (Libraries)"]
    NPM --> DEP
    DEP --> APP["Application Codebase"]
    SYS --> B_RT["Independent Runtime/PM (e.g. Bun)"]
    B_RT --> DEP

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"]

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 ecosystems that support version managers, require the user to install those before working with the ecosystem. Let them choose which one they want to use, then install that one. For any new project, allow them to choose again. support the 3 most popular version managers for each ecosystem.

ecosystems to target:

  • Web

  • System languages

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.