L4inner-loop

CLI Platform

When I need to manage projects, communicate with engineering, audit system health, or measure outcomes — drmg is the single control surface that works for both human operators and AI agents.

1,200

Priority Score

Pain × Demand × Edge × Trend × Conversion

Customer Journey

Why should I care?

Five cards that sell the dream

1Why

Five CLIs, one binary.

What if every CLI command shared one platform library?

The friction: Five independent CLIs means five arg parsers, five env loaders, five output formats. Every new script reinvents the wheel.

The desire: One binary (drmg) that routes to all commands. Shared platform lib handles parsing, output, env, and DB context.

The proof: 9 namespaces, 60+ commands, zero duplicate infrastructure.

Architecture map

Picture

Five terminal windows merging into one — cables converging on a single dark console. Cinematic, 16:9

2Evidence

3,826 lines must split.

How do you decompose a working monolith without breaking 40 commands agents depend on daily?

Plan-cli was a 3,826-line monolith handling 40+ commands. One change risked breaking everything. Module-per-domain decomposition: lifecycle, audit, tasks, sessions, data. Thin redirects preserved backward compat.

Before	After
3,826-line monolith	5 domain modules
4 duplicate arg parsers	1 shared Zod parser
Direct SQL in scripts	Repository-only access
0 introspection	drmg describe → JSON schema

Migration stories

Picture

A monolith cracking into five clean modules — each module glowing with its domain color. Dark background. Cinematic, 16:9

3Platform

Agents can't see commands.

How does an agent orchestrate tools it can't describe?

Before: No runtime introspection. Agents can't discover what commands exist, what args they take, or what they return. Hardcoded paths everywhere.

After: Every command exports a Zod schema. drmg describe returns JSON metadata for any command namespace. Agents compose workflows dynamically.

The pattern: Introspection is table stakes for agentic systems. If the tool can't describe itself, the agent can't use it.

Introspection stories

Picture

An AI agent facing a dark wall of commands — no labels, no schema, no way to know what's available. Cinematic, 16:9

4Loop

Foundation first, enforce last.

What's the right build order when enforcement depends on the alternative existing?

Phase	Ships	Proves
1	Platform lib (8 concerns)	Shared infrastructure works
2	Monolith decomposition	40+ commands preserved
3	CLI absorption	ETL, Comms, Data, Measure unified
4	Unified router + describe	One binary, runtime introspection
5	Boundary enforcement	Direct DB imports impossible

Build order

Picture

Five building blocks stacking in sequence — platform lib at the base, ESLint rule at the top. Each block lights up as it completes. Cinematic, 16:9

5People

Repository layer is law.

How do you enforce a boundary when convenience always wins?

Who	Their job
Agent orchestrator	Discover + compose CLI commands at runtime
Operator	One binary, stop remembering 5 entry points
Contributor	ESLint blocks direct DB access — can't bypass repos

Kill signal: No new CLI added in 90 days, or agents stop using plan-cli. Neither has triggered.

Enforcement stories

Picture

A red lint error in a terminal — 'Direct DB import blocked. Use repository layer.' — with an arrow pointing to the correct import path. Cinematic, 16:9

1 / 5

Same five positions. Different seat.

The operator sees one binary. The agent sees runtime introspection. The contributor sees enforced boundaries. The platform sees compounding extraction.

Feature Dev Journey

How did this get built?

Five cards that show the process

1Job

The job: extract, don't invent.

What proven patterns already exist across 5 CLIs?

Situation: Five CLIs built independently. 4 duplicate arg parsers, 4 env loaders, 2+ direct SQL scripts. Every session pays the duplication tax.

Intention: 8 shared concerns extracted into one platform lib. Every "Custom" or "Direct" cell in the capability matrix is a duplication cost.

Obstacle: The 3,826-line monolith. Decomposing it without breaking 40+ daily commands.

Intent contract

Picture

A capability matrix — 8 rows (concerns) x 5 columns (CLIs). Custom/Direct cells highlighted in red, shared cells in green. Cinematic, 16:9

2Stories

Four stories, four contracts.

If the test doesn't name a data source and threshold, what are you actually testing?

Story	THEN assertion	Forbidden
S1: Discover	JSON schema for any namespace	Empty on valid command
S2: Compat	Output matches legacy exactly	Format or data differs
S3: Dry-run	Preview without writing to DB	Flag silently ignored
S4: Boundary	ESLint blocks direct DB import	Import passes CI

Full story contracts

Picture

A test dashboard — four story IDs all green. Dark background, terminal aesthetic. Cinematic, 16:9

3Build

80% extraction, 20% new code.

What already exists that you haven't wired yet?

Job	Rows	Nature
Platform lib	8	Extract proven patterns
Monolith decomposition	5	Split by domain
CLI absorption	4	Wire to platform lib
Unified router	3	New code
Boundary enforcement	2	New code

Capability map

Picture

A pie chart: 80% extraction (blue), 20% new (crimson). Router and ESLint rule are the only new code. Cinematic, 16:9

4Sprints

Five phases, foundation first.

What's the right build order when enforcement depends on the alternative existing?

Build order: Platform lib → Monolith split → CLI absorption → Unified router → Boundary enforcement. ESLint rule comes last because you need somewhere to migrate TO before blocking the old path.

L2 verified when: drmg plan active produces identical output to legacy plan-cli active.

Build order diagram

Picture

Five phases on a timeline — each phase lights up as it ships. Foundation at left, enforcement at right. Cinematic, 16:9

5Validation

All 22 rows at Live.

What's the cost of not consolidating — measured in drift incidents, not developer minutes?

Status: Completed. 9 namespaces, 60+ commands, unified binary. All build contract rows at Live. ESLint boundary rule enforced in CI.

Gate	Evidence
L2	drmg plan active matches legacy output
L3	All 40+ commands routed, zero breakage
L4	ESLint blocks direct DB imports in CI

Commissioning evidence

Picture

A build contract table — all 22 rows showing green 'Live' badges. Dark background, terminal aesthetic. Cinematic, 16:9

1 / 5

The pitch is the shape. The flow diagrams prove the thinking. The VV stories validate the value.

Flow Diagrams VV Stories

Problem

Situation

Dream team and agents interface with the stackmates system through the drmg CLI daily — plan dashboard, comms read/post, audit, measure, data gaps. The CLI works but doesn't report what operators need: plans drift without stale warnings, dashboards show plan IDs not project names, merged PRs leave plan DB out of sync, session boundaries aren't queryable, and error messages assume you already know the fix.

Intention

An agent-grade CLI control surface scored 16/20 on the 10-dimension CLI Standard — structured I/O, runtime introspection, context discipline, input hardening, safety rails, response safety, packaged guidance, multi-surface coherence, headless auth, and failure design.

Obstacle

The CLI was built to solve engineering problems (monolith decomposition, boundary enforcement). Operator and agent needs were bolted on, not designed in. Dashboard output is plan-centric, not project-centric. Error recovery requires tribal knowledge. No batch operations. No staleness detection.

Hardest Thing

Reframing a working CLI from 'does it run commands' to 'does it give operators and agents the information they need to make decisions' — without breaking 60+ commands agents depend on daily.

Scorecard

Priority (5P)

5/5

Pain

4/5

Demand

4/5

Edge

5/5

Trend

3/5

Convert

Readiness (5R)

Principles5 / 5

Performance4 / 5

Platform5 / 5

Process4 / 5

Players3 / 5

What Exists

Component	State	Gap
drmg unified binary	Working	9 namespaces, 60+ commands routed through single entry point.
libs/cli-platform	Working	Shared arg-parser, output formatter, env-loader, db-context, dry-run, introspection.
Plan CLI (decomposed)	Working	40+ commands split across 5 domain modules.
ETL CLI (absorbed)	Working	8 live pipelines using shared platform lib.
Comms CLI (absorbed)	Working	Read/post via shared platform lib.
ESLint boundary rule	Working	Blocks direct DB imports in tools/scripts/.
drmg describe	Working	JSON schema introspection for all command namespaces.

Relationships

PRD	Contributes
Agent Platform	Parent platform this instrument serves. Agents use drmg for all CLI operations.
Project Management	Plan-cli is the most-used CLI. Decomposition was driven by plan-cli's 3,826-line monolith.
ETL Data Tool	ETL CLI absorbed into drmg. 8 live pipelines share platform lib.

Kill Signal

CLI Standard score drops below 12/20 for two consecutive sprints, or agents abandon drmg for direct script calls. Neither has triggered.

Questions

If the CLI is the control surface for the entire system, what's the cost of every operator workaround that should be a command?

How many decisions per session are delayed because the dashboard requires 4 commands instead of 1?
What's the cost of plan-DB drift — measured in wrong priorities acted on, not minutes to sync?
If an agent can't distinguish 'no messages' from 'connection broken', what decisions does it make on false data?