#276 [Feat] Headless terminal distribution: run DevProjex as a .NET tool via dnx

[Anonymous]

Originally created by: Avazbek22

Summary

The most common adoption objection we hear is not about features — it is about weight and friction: "Repomix runs through npx with zero install; DevProjex makes me download a desktop app." The objection is fair. Today the only distribution is a full self-contained bundle (81–264 MB per platform in v5.1) that carries the entire Avalonia GUI even when the consumer needs one CLI command in a CI job.

This issue adds a headless terminal distribution: a slim console binary with the full CLI + TUI + MCP surface and no GUI, packaged as a .NET tool so that .NET 10 users can run

dnx devprojex tree .

with no installation step at all, and CI pipelines can run the secrets gate as a one-liner.

Strategic context: as of 2026-09-04, NuGet has zero context-packing tools — Repomix lives on npm, gitingest on PyPI, code2prompt on crates.io. Nobody serves the .NET ecosystem through its native channel, and the devprojex package ID is free. This is a first-mover position, not a catch-up.

Foundation: a headless host project

The codebase is already shaped for this. DevProjex.Terminal is a library with no Avalonia reference (Spectre.Console, System.CommandLine, Terminal.Gui, plus DevProjex.Mcp and the core layers), and TerminalApplication takes an optional developerCommandRunner — the Avalonia-specific piece is injected only by the desktop host.

Work:

• New console host project (working name Apps/TerminalHost, AssemblyName devprojex, OutputType Exe) that constructs TerminalApplication without the desktop runner. No routing layer needed — every invocation is terminal mode.
• Desktop-control commands (desktop …) must degrade with an actionable message ("this distribution has no GUI; install the desktop app from …"), not a crash or a silent no-op.
• Grammar delivery is already RID-aware (DevProjexGrammarRuntimeIdentifier, vendored per-RID payloads of ~3.7 MB), so the slim host inherits code compression without new plumbing.

Packaging: .NET 10 RID-specific tool packages

.NET 10 supports platform-specific tool packages: PackAsTool plus ToolPackageRuntimeIdentifiers produces one top-level pointer package and one self-contained package per RID; dnx / dotnet tool install download only the pointer plus the single matching RID package. Self-contained RID packages run on machines without a .NET runtime; dnx itself ships with SDK 10.0.100+.

Decisions to make during implementation:

• RID set: win-x64, win-arm64, linux-x64, linux-arm64, osx-x64, osx-arm64 (mirrors current release artifacts).
• Whether to include an any framework-dependent fallback package for platforms outside the RID set.
• CoreCLR self-contained vs Native AOT per RID. AOT gives the best cold start but cannot cross-compile between operating systems, so packing federates across the existing CI OS matrix. CoreCLR self-contained is a fine first ship; AOT can be a follow-up.
• Pre-.NET-10 SDKs cannot consume the new package schema ("unsupported runner"). Proposal: document SDK 10+ as the requirement rather than shipping the dual-schema workaround.

Release pipeline: publish all RID packages first, then the pointer package, same version — installs fail if the order or versions diverge. Wire into the existing release scripts next to the GitHub/Store/winget steps.

CI story

With the tool package in place, the secrets pre-flight gate becomes a two-step recipe worth documenting prominently:

- uses: actions/setup-dotnet@v5
  with:
    dotnet-version: 10.0.x
- run: dnx devprojex analyze . --findings --fail-on-findings --yes

Docs/CommandLine.md gets a "Run without installing" section; README gets the dnx devprojex one-liner next to the download links.

Non-goals

• No GUI in the tool package — the desktop app keeps shipping through GitHub releases, Microsoft Store, and winget unchanged.
• No JS/npm packaging in this issue — that is a separate distribution channel with its own mechanics (tracked separately).
• No new CLI behavior: the slim host exposes the existing surface, byte-for-byte identical output contracts.

Acceptance criteria

• dnx devprojex --version and dnx devprojex tree . work on a clean Windows/Linux/macOS machine with only the .NET 10 SDK installed.
• dotnet tool install -g devprojex works and puts devprojex on PATH.
• Terminal command matrix (CLI contract tests) passes against the slim host, not only the desktop host.
• desktop commands in the slim distribution fail with the documented actionable message.
• Per-RID package size is reported in the release notes; the slim payload must be a small fraction of the full desktop bundle.
• Release pipeline publishes the packages automatically with the correct ordering; a dry-run mode exists for validation.
• Docs updated together with the implementation: README, Docs/CommandLine.md, Docs/McpServer.md (MCP server startup via dnx).

[Anonymous]

Originally posted by: Avazbek22

Before this channel first publishes, it needs the completeness gate and functional smoke required by [#278] — the NuGet RID packages join the same payload-manifest validation as the existing channels.