Skip to main content
Glama
README.md
# Lockstep Chain Protocol

Chain-based project tracking for Human+AI collaboration. An MCP server that gives your AI coding assistant persistent memory across sessions — chains link work together, tickets track what needs doing, and handoffs preserve context so nothing gets lost between conversations.

## Who is this for?

Anyone using AI coding assistants (Claude, etc.) who's tired of re-explaining context every session. Lockstep is especially useful if you:

- Work on multi-session projects where continuity matters
- Want structured session types (discovery, planning, build, review) without rigid enforcement
- Are neurodivergent and benefit from external scaffolding for executive function
- Want your AI partner to track growth and capacity over time

## Features

- **37 tools + 5 commands** for full project lifecycle management
- **Chain-based tracking** — sessions link together as a chain of work
- **YAML-defined chain types** — full-funnel, enhancement, refactor, bug-fix out of the box, or create your own
- **Progressive disclosure** — early phases show fewer fields to reduce cognitive load; information surfaces as it becomes relevant
- **Ticket promotion** — standalone tickets can be promoted into chains when they grow; related tickets discovered automatically
- **Session types** — discovery, research, planning, architecture, build, review
- **Structured handoffs** — decisions, files changed, open threads, and next-session recommendations transfer between conversations
- **Capacity tracking** — growth stages (training-wheels → partnership → safety-net) with event logging
- **Advisory, not enforcing** — the protocol flags and explains, never blocks
- **Fully local** — all data stored as YAML files on your machine, no network access
- **Cross-platform** — tested on macOS, Windows 11, and Linux (x64 and ARM)
- **Human-readable data** — inspect, edit, or version-control your project data directly

## Installation

### From Anthropic Directory (Claude Desktop)

1. Find "Lockstep Core" in the Anthropic Directory
2. Click Install
3. When prompted, choose a data directory (default: `~/.lockstep/data`)

### MCPB Bundle (Manual)

1. Download `lockstep-core.mcpb` from the [latest release](https://github.com/dandelionrosegroup/lockstep-core/releases)
2. Open it with Claude Desktop (double-click or drag in)
3. When prompted, choose a data directory (default: `~/.lockstep/data`)

### Manual Setup

Requires [uv](https://docs.astral.sh/uv/) and Python 3.11+. Works on macOS, Windows, and Linux.

```bash
git clone https://github.com/dandelionrosegroup/lockstep-core.git
cd lockstep-core
```

Add to your Claude Desktop config:

| Platform | Config Location |
|----------|----------------|
| macOS | `~/Library/Application Support/Claude/claude_desktop_config.json` |
| Windows | `%APPDATA%\Claude\claude_desktop_config.json` |
| Linux | `~/.config/Claude/claude_desktop_config.json` |

**macOS / Linux:**

```json
{
  "mcpServers": {
    "lockstep": {
      "command": "uv",
      "args": ["run", "--python", "3.11", "--with", "mcp>=1.0.0", "--with", "pydantic>=2.0.0", "--with", "PyYAML>=6.0", "src/server.py"],
      "cwd": "/path/to/lockstep-core",
      "env": {
        "LOCKSTEP_DATA_DIR": "/path/to/your/data",
        "PATH": "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/homebrew/bin:~/.local/bin"
      }
    }
  }
}
```

> **Important:** Claude Desktop is a GUI app and does not inherit your shell's PATH. The `PATH` entry above ensures `uv` (typically installed at `~/.local/bin/uv`) is discoverable. If you installed uv via Homebrew, `/opt/homebrew/bin` covers that path.

**Windows:**

```json
{
  "mcpServers": {
    "lockstep": {
      "command": "uv",
      "args": ["run", "--python", "3.11", "--with", "mcp>=1.0.0", "--with", "pydantic>=2.0.0", "--with", "PyYAML>=6.0", "src/server.py"],
      "cwd": "C:\\Users\\you\\Projects\\lockstep-core",
      "env": {
        "LOCKSTEP_DATA_DIR": "C:\\Users\\you\\.lockstep\\data"
      }
    }
  }
}
```

> **Note:** On Windows, use double backslashes (`\\`) or forward slashes (`/`) in JSON paths.

### Troubleshooting

**"uv: command not found" or server fails to start:**
Claude Desktop doesn't inherit your terminal's PATH. Make sure `uv` is findable:
- **macOS/Linux:** Add the `PATH` env var as shown in the config example above, or use the full path to uv (e.g., `"command": "/Users/you/.local/bin/uv"`)
- **Windows:** The uv installer usually adds itself to the system PATH. If not, use the full path (e.g., `"command": "C:\\Users\\you\\.local\\bin\\uv.exe"`)

**Server starts but immediately disconnects:**
- Verify Python 3.11+ is available: `uv python list` (uv will auto-download if needed thanks to the `--python 3.11` flag)
- Check Claude Desktop's MCP logs: `~/Library/Logs/Claude/mcp*.log` (macOS) or `%APPDATA%\Claude\logs\` (Windows)

## Configuration

Lockstep needs one setting: a **data directory** where it stores chains, tickets, and capacity data.

- **Default:** `~/.lockstep/data`
- **Custom:** Set `LOCKSTEP_DATA_DIR` environment variable or configure during MCPB install
- Lockstep creates subdirectories automatically (`chains/`, `tickets/`, `capacity/`, `declarations/`, `handoffs/`, `catches/`, `archive/`)

## Usage Examples

### Start a new initiative

Create a ticket, chain, and first session in one command.

**User prompt:**
> "Create a new initiative called 'Build user authentication' with the vision 'Users can sign up, log in, and manage their accounts.'"

**Tool call:** `cmd_new_initiative`

```json
{
  "title": "Build user authentication",
  "vision": "Users can sign up, log in, and manage their accounts."
}
```

**Response:**
```json
{
  "ticket_id": "TICKET-001",
  "chain_id": "build-user-authentication",
  "chain_type": "full-funnel",
  "first_session": "discovery",
  "link_number": 1,
  "message": "Initiative created. Discovery session is active. Record your session declaration."
}
```

### Promote a ticket into a chain

When a standalone ticket grows in scope, promote it to get chain tracking with automatic discovery of related work.

**User prompt:**
> "Promote TICKET-005 into a chain. The completion vision is 'OAuth fully integrated and tested.'"

**Tool call:** `promote_ticket`

```json
{
  "ticket_id": "TICKET-005",
  "completion_vision": "OAuth fully integrated and tested"
}
```

**Response:**
```json
{
  "promoted": true,
  "ticket_id": "TICKET-005",
  "chain_id": "add-oauth-support",
  "chain_type": "enhancement",
  "first_session": "planning",
  "nesting_candidates": [
    {
      "ticket_id": "TICKET-008",
      "title": "Review Auth Flows",
      "shared_tags": ["auth"]
    }
  ],
  "candidate_message": "Found 1 related ticket(s) that could be nested.",
  "message": "Ticket promoted to chain 'add-oauth-support'. Planning session is active."
}
```

### Record a handoff

Capture session context so the next conversation can pick up seamlessly.

**User prompt:**
> "Record a handoff — we decided on JWT tokens and bcrypt for passwords. Files changed: auth.py (created), models.py (modified). Next session should be Planning."

**Tool call:** `record_handoff`

```json
{
  "chain_id": "build-user-authentication",
  "session_type": "discovery",
  "status": "complete",
  "decisions_made": ["JWT tokens for auth", "bcrypt for password hashing"],
  "files_changed": [
    {"path": "auth.py", "action": "created"},
    {"path": "models.py", "action": "modified"}
  ],
  "recommended_next_type": "planning",
  "quick_start": "Define API routes, data models, and auth middleware based on JWT+bcrypt decisions."
}
```

## Tools Reference

### Chain Lifecycle (15 tools)
| Tool | Description |
|------|-------------|
| `create_chain` | Create a new chain from a ticket |
| `read_chain` | Read chain state (filtered by progressive disclosure) |
| `get_chain_status` | Lightweight status check |
| `set_chain_status` | Update chain status |
| `set_chain_entity` | Tag chain with entity ownership |
| `update_chain_metadata` | Update vision, entity, capacity role |
| `add_chain_link` | Add a new session link |
| `complete_chain_link` | Mark a link as complete |
| `pause_chain` | Pause chain (preserves state) |
| `resume_chain` | Resume a paused chain |
| `complete_chain` | Mark chain complete (auto-closes ticket for bug-fix/maintenance) |
| `archive_chain` | Move to archive with retention metadata |
| `branch_chain` | Fork when work splits |
| `spawn_child_chain` | Cross-type fork with spawn reason (e.g. infrastructure → content) |
| `rename_chain` | Rename chain and update all cross-references |

### Ticket Lifecycle (7 tools)
| Tool | Description |
|------|-------------|
| `create_ticket` | Create ticket with auto-assigned ID |
| `read_ticket` | Read full ticket state |
| `update_ticket` | Update metadata and append notes (returns promotion nudge at 3+ notes) |
| `close_ticket` | Close ticket (advisory: flags if chain incomplete) |
| `tag_ticket` | Add or remove tags (returns promotion nudge if applicable) |
| `link_ticket_chain` | Associate ticket with chain (auto-detects child tickets) |
| `promote_ticket` | Promote standalone ticket into a chain with candidate scanning |

### Capacity Tracking (5 tools)
| Tool | Description |
|------|-------------|
| `read_capacity` | Read capacity role data |
| `update_capacity_stage` | Transition between growth stages |
| `record_capacity_event` | Log a capacity-relevant event |
| `get_capacity_events` | Query capacity event history |
| `check_stagnation` | Check for stalled growth |

### Query Tools (6 tools)
| Tool | Description |
|------|-------------|
| `search_chains` | Filter chains by entity, status, type, date |
| `list_chains` | List all active chains |
| `search_tickets` | Filter tickets by type, entity, priority |
| `list_tickets` | List all open tickets |
| `get_dashboard` | Overview with progressive disclosure per chain phase |
| `check_chain_health` | Find stale or blocked chains |

### Session Support (4 tools)
| Tool | Description |
|------|-------------|
| `record_session_declaration` | Write session declaration (goal, deliverable, criteria) |
| `record_handoff` | Write session-end handoff with context for next session |
| `record_gate_skip` | Log when session type sequence is skipped |
| `record_catch_event` | Log scope drift or momentum shift |

### Commands (5 shortcuts)
| Command | Description |
|---------|-------------|
| `cmd_new_ticket` | Create a ticket (generic) |
| `cmd_new_initiative` | Ticket + full-funnel chain + discovery session |
| `cmd_enhancement` | Ticket + enhancement chain + planning session |
| `cmd_refactor` | Ticket + refactor chain + architecture session |
| `cmd_bug_fix` | Bug-fix ticket, optionally with chain |

## Creating Custom Chain Types

Chain types are defined as YAML files in `templates/`. Drop a new file to create a new chain type — no code changes required.

### Template Format

```yaml
# templates/your-type.yaml
chain_type: your-type
display_name: Your Type
phases: [planning, build, review]
autonomous_eligible: false
required_fields:
  - completion_vision
optional_fields:
  - capacity_role
  - parent_chain
progressive_disclosure:
  planning:
    show: [completion_vision, entity, tags]
    prompt: "What are we building and why?"
  build:
    show: [all]
    prompt: null
  review:
    show: [all]
    prompt: "Does this meet the completion vision?"
```

### Fields

| Field | Required | Description |
|-------|----------|-------------|
| `chain_type` | Yes | Unique identifier (kebab-case) |
| `display_name` | Yes | Human-readable name |
| `phases` | Yes | Ordered list of session types this chain walks through |
| `autonomous_eligible` | No | Can AI proceed without human review? (default: false) |
| `required_fields` | No | Fields required at chain creation |
| `optional_fields` | No | Fields that may be set later |
| `progressive_disclosure` | No | Per-phase field visibility and prompts |

### Progressive Disclosure

Each phase can define:
- **`show`**: List of chain fields visible during this phase. Use `[all]` to show everything.
- **`prompt`**: Optional guidance text surfaced to the AI partner during this phase.

Available fields for `show`: `completion_vision`, `entity`, `tags`, `capacity_role`, `parent_chain`, `child_chains`, `child_tickets`, `spawn_reason`, `expected_sequence`, `gate_skips`, `all`.

Core structural fields (`chain_id`, `title`, `status`, `links`, etc.) are always visible regardless of disclosure rules.

### Built-in Chain Types

| Type | Phases | Autonomous |
|------|--------|-----------|
| `full-funnel` | discovery → research → planning → architecture → build → review | No |
| `enhancement` | planning → architecture → build → review | No |
| `refactor` | architecture → build → review | No |
| `bug-fix` | build → review | Yes |

## Migrating from v0.1.0

If you have existing v0.1.0 data, run the migration script:

```bash
python scripts/migrate_v1_to_v2.py ~/.lockstep/data
```

This creates a backup, renames `template` to `chain_type`, and bumps the schema version. The server also auto-migrates any v1 files it encounters on read, so migration is optional but recommended for clean data.

## Design Principles

1. **Advisory, not enforcing.** The protocol flags and explains — it never blocks. If you want to skip from Discovery straight to Build, it records the skip and moves on.
2. **Make the unconscious conscious.** Session handoffs, catch events, and capacity tracking illuminate patterns over time without forcing behavior change.
3. **Scaffold growth, respect autonomy.** Growth stages (training-wheels → partnership → safety-net) make the path of least resistance the productive path, but they're never the only path.
4. **Protocol serves partnership.** If the structure fights the work, the structure bends.

## Data Storage

All data is stored as YAML files in your configured data directory:

```
~/.lockstep/data/
├── chains/          # CHAIN-[kebab-title].yaml
├── tickets/         # TICKET-[number].yaml
├── capacity/        # [role-name].yaml
├── declarations/    # Session declaration records
├── handoffs/        # Session handoff records
├── catches/         # Catch event records
└── archive/         # Completed chains and tickets
    ├── chains/
    └── tickets/
```

YAML files are human-readable and version-controllable. No database required.

## Privacy Policy

Lockstep is a fully local MCP server. It collects no data, makes no network requests, and includes no telemetry. Your project data stays on your machine.

Full policy: [PRIVACY.md](PRIVACY.md)

## Support

- **Issues:** [github.com/dandelionrosegroup/lockstep-core/issues](https://github.com/dandelionrosegroup/lockstep-core/issues)
- **Discussions:** [github.com/dandelionrosegroup/lockstep-core/discussions](https://github.com/dandelionrosegroup/lockstep-core/discussions)

## Contributing

Lockstep is GPL v3 licensed. Contributions welcome. Tested on macOS, Windows 11, and Linux.

```bash
# Set up development environment
git clone https://github.com/dandelionrosegroup/lockstep-core.git
cd lockstep-core

# Run tests (uv handles dependencies automatically)
uv run --python 3.11 --with mcp --with pydantic --with PyYAML python tests/test_integration.py
uv run --python 3.11 --with mcp --with pydantic --with PyYAML python tests/test_phase2_promotion.py
uv run --python 3.11 --with mcp --with pydantic --with PyYAML python tests/test_phase3_disclosure.py

# Or run all tests with pytest (requires pytest + pytest-asyncio)
uv run --python 3.11 --with mcp --with pydantic --with PyYAML --with pytest --with pytest-asyncio \
  python -m pytest tests/ -v
```

Check [open issues](https://github.com/dandelionrosegroup/lockstep-core/issues) for good places to start.

## License

[GNU General Public License v3.0](LICENSE) — Copyright (C) 2025-2026 Jack Daniel Williams / Dandelion Rose Group, LLC

Built as part of [Dandelion Rose Group](https://github.com/dandelionrosegroup)'s mission to prove that neurodivergent minds are uniquely wired for AI partnership.

TDQS

C2.9/5.0

Scored across 42 tools

Disambiguation3/5

Several tools have overlapping retrieval or lifecycle roles: list_tickets/search_tickets, create_ticket/cmd_new_ticket, read_chain/get_chain_status/check_chain_health, and branch_chain/spawn_child_chain can be confused. Descriptions differentiate most cases, but an agent must read carefully to choose correctly.

Naming Consistency4/5

All names use snake_case with a mostly consistent verb_noun pattern. Retrieval verbs are mixed (read_/get_/list_) and the cmd_* family uses a distinct prefix convention, but the set remains readable and predictable.

Tool Count2/5

42 tools is well above the typical 3-15 sweet spot and exceeds the 25+ heavy threshold. Many lifecycle and command variants could be consolidated without losing core capability.

Completeness4/5

The surface covers chain/ticket CRUD, linking, promotion, capacity tracking, dashboards, session declarations/handoffs, and command shortcuts. Gaps include no explicit delete/reopen operations and limited direct editing of existing chain links, but core workflows are covered.

Maintenance

ActivityInactive
ResponsivenessNo issues