Metadata-Version: 2.4
Name: lim-mm-cli
Version: 0.3.0
Summary: CLI tool for LIM-compatible micro model project scaffolding
Author-email: Solution Eden <solutionedencom@gmail.com>
Requires-Python: >=3.7
Description-Content-Type: text/markdown
License-File: LICENSE
Requires-Dist: typer
Requires-Dist: jsonschema
Requires-Dist: requests
Dynamic: license-file

# LIM MM CLI: Command Line Interface for Micro Model Management

## 🎯 LIM Concept
**LIM (Large Integration Model)** aims to be an open source, realtime data retrieval and micro model training enhancement framework.

### Philosophy: "Human Socialism Model Network"
LIM represents a paradigm shift from monolithic "God Models" (LLMs) to a **decentralized, collaborative network of specialized intelligence**.

- **Socialism of Intelligence**: Democratized AI through community-driven micro models.
- **Model on the Air**: Intelligence is fluid. MMs are lightweight, rapidly trainable, and deployable (MaaS).
- **The Anti-Monolith**: Unlike traditional LLMs, LIM routes intent to the *exact* source of truth or specialist model.
- **LIM > MCP**: While MCP standardizes connections, LIM resolves the *execution* problem by autonomously routing queries.

## Core Architecture (The L-I-M Trinity)

### **L** - Large Integration Model (The Conductor)
- **Role**: Intent Understanding & Routing.
- **Function**: The "Generalist" that parses queries and directs them into the network.

### **I** - Integration Network (The Nervous System)
- **Role**: Discovery, Transport, & Protocol.
- **Function**: The infrastructure layer connecting the Conductor to the Specialists.

### **M** - Micro Model (The Specialist) / MMS
- **Role**: Domain-Specific Execution.
- **Philosophy**: Minimize context, rapid training, and hot-swappable.

## CLI Commands
The CLI exposes two entry points: `mm` (Micro Model lifecycle) and `lim`
(LIM node). The `mm` commands are also mounted under `lim`, so the canonical
`launch_command` `lim mm run` works as well as the shorter `mm run`.

### Project Management
```bash
mm start <name>            # Create a new micro model project from template
mm validate [-H URL]       # Validate res.json (schema + URL policy); with -H, live-check the service
mm build                   # Containerize the current MM (docker compose build)
mm run                     # Execute the project locally (python run/start.py -> docker compose up -d)
mm stop                    # Stop the containers started by `mm run` (docker compose down)
```

### Registry Operations
```bash
mm push                    # Publish the MM to the LIM(s) in integration.lim
mm distribute [-t URL]     # Register the MM with a local LIM node (default: http://localhost:8000)
mm pull <mm1,mm2>          # Git-clone MMs into limmm/mm/ (names via integration.mm, or git URLs)
mm list [name]             # List MMs under limmm/mm/ (or show one MM's metadata)
```

### LIM node
```bash
lim validate               # Validate this LIM node's res.json
lim push                   # Start the LIM and verify its /res.json matches res.json
lim mm <command>           # Same Micro Model commands, namespaced under lim
```

> **Local distribution**: `mm distribute` reuses the `push` contract but targets a
> single *local* LIM instead of the cloud LIM(s) listed in `integration.lim`. The
> target resolves from `--target/-t`, then `$LIM_LOCAL_URL`, then
> `http://localhost:8000`. Use it to register a model on the local network with no
> cloud dependency.

> **Git-based pull**: `mm pull` clones each MM into `limmm/mm/<repo>` ("take your
> AI experts home"). A plain name is resolved through this LIM's `res.json`
> (`integration.mm[]` → the MM's live `/res.json` → `repository.url`, honoring
> `branch` and a pinned `commit`); a git URL is cloned directly. If the target
> directory already exists as a git repo, it is fast-forwarded instead.

## Micro Model Service (MMS) Standard
All MMs must adhere to the Open Source MMS Standard for interoperability:

### Structure
- **`res.json`**: The contract. Defines input/output schemas and configuration.
- **`mms/`**: Service logic (API, Agents, RAG).
- **`models/`**: Model artifacts (weights, embeddings).
- **`data/`**: Specialized datasets or knowledge base.
- **`run/`**: Execution scripts & Docker config.

```
my-model/
├── res.json                # Model contract and metadata
├── mms/                    # Service implementation (the Quart app)
│   ├── app/                # Application logic (blueprints, routes)
│   ├── tests/              # Tests
│   ├── .env                # 12-Factor runtime config
│   └── requirements.txt    # Service dependencies
├── models/                 # AI Model artifacts
├── data/                   # Domain-specific data
├── run/
│   ├── server.py           # ASGI entrypoint (uvicorn run.server:app)
│   ├── start.py            # Launcher (docker compose up --build)
│   └── docker/             # Dockerfile, docker-compose.yml, entrypoint.sh
└── README.md               # Documentation
```

The scaffold produced by `mm start` is **immediately runnable**: `mm run` boots
the service with `uvicorn run.server:app` inside Docker (HTTP in dev mode so a
local LIM can reach it over the `http://` base_url in `res.json`).

### Protocol
- **Discovery**: Must expose `<host>:8000/res.json` (served by the app).
- **Git-Based**: MMs are versioned and distributed via Git repositories.

## Getting Started

1. **Install the CLI**:
   ```bash
   pip install lim-mm-cli
   ```

2. **Create a new model**:
   ```bash
   mm start my-model
   cd my-model
   ```

3. **Configure & Validate**:
   Edit `res.json` and run:
   ```bash
   mm validate
   mm run
   ```

4. **Deploy**:
   ```bash
   mm build
   mm push
   ```

## Technology Stack
- **Backend**: Python, Quart (Async)
- **Infra**: Docker, PostgreSQL
- **Ops**: Loki, Grafana
- **Interface**: CLI, REST API
