Lockstep Core
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Lockstep Core start a new chain for the homepage redesign"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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
Related MCP server: Adaptive Reasoning Server
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)
Find "Lockstep Core" in the Anthropic Directory
Click Install
When prompted, choose a data directory (default:
~/.lockstep/data)
MCPB Bundle (Manual)
Download
lockstep-core.mcpbfrom the latest releaseOpen it with Claude Desktop (double-click or drag in)
When prompted, choose a data directory (default:
~/.lockstep/data)
Manual Setup
Requires uv and Python 3.11+. Works on macOS, Windows, and Linux.
git clone https://github.com/dandelionrosegroup/lockstep-core.git
cd lockstep-coreAdd to your Claude Desktop config:
Platform | Config Location |
macOS |
|
Windows |
|
Linux |
|
macOS / Linux:
{
"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
PATHentry above ensuresuv(typically installed at~/.local/bin/uv) is discoverable. If you installed uv via Homebrew,/opt/homebrew/bincovers that path.
Windows:
{
"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
PATHenv 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.11flag)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/dataCustom: Set
LOCKSTEP_DATA_DIRenvironment variable or configure during MCPB installLockstep 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
{
"title": "Build user authentication",
"vision": "Users can sign up, log in, and manage their accounts."
}Response:
{
"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
{
"ticket_id": "TICKET-005",
"completion_vision": "OAuth fully integrated and tested"
}Response:
{
"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
{
"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 a new chain from a ticket |
| Read chain state (filtered by progressive disclosure) |
| Lightweight status check |
| Update chain status |
| Tag chain with entity ownership |
| Update vision, entity, capacity role |
| Add a new session link |
| Mark a link as complete |
| Pause chain (preserves state) |
| Resume a paused chain |
| Mark chain complete (auto-closes ticket for bug-fix/maintenance) |
| Move to archive with retention metadata |
| Fork when work splits |
| Cross-type fork with spawn reason (e.g. infrastructure → content) |
| Rename chain and update all cross-references |
Ticket Lifecycle (7 tools)
Tool | Description |
| Create ticket with auto-assigned ID |
| Read full ticket state |
| Update metadata and append notes (returns promotion nudge at 3+ notes) |
| Close ticket (advisory: flags if chain incomplete) |
| Add or remove tags (returns promotion nudge if applicable) |
| Associate ticket with chain (auto-detects child tickets) |
| Promote standalone ticket into a chain with candidate scanning |
Capacity Tracking (5 tools)
Tool | Description |
| Read capacity role data |
| Transition between growth stages |
| Log a capacity-relevant event |
| Query capacity event history |
| Check for stalled growth |
Query Tools (6 tools)
Tool | Description |
| Filter chains by entity, status, type, date |
| List all active chains |
| Filter tickets by type, entity, priority |
| List all open tickets |
| Overview with progressive disclosure per chain phase |
| Find stale or blocked chains |
Session Support (4 tools)
Tool | Description |
| Write session declaration (goal, deliverable, criteria) |
| Write session-end handoff with context for next session |
| Log when session type sequence is skipped |
| Log scope drift or momentum shift |
Commands (5 shortcuts)
Command | Description |
| Create a ticket (generic) |
| Ticket + full-funnel chain + discovery session |
| Ticket + enhancement chain + planning session |
| Ticket + refactor chain + architecture session |
| 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
# 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 |
| Yes | Unique identifier (kebab-case) |
| Yes | Human-readable name |
| Yes | Ordered list of session types this chain walks through |
| No | Can AI proceed without human review? (default: false) |
| No | Fields required at chain creation |
| No | Fields that may be set later |
| 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 |
| discovery → research → planning → architecture → build → review | No |
| planning → architecture → build → review | No |
| architecture → build → review | No |
| build → review | Yes |
Migrating from v0.1.0
If you have existing v0.1.0 data, run the migration script:
python scripts/migrate_v1_to_v2.py ~/.lockstep/dataThis 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
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.
Make the unconscious conscious. Session handoffs, catch events, and capacity tracking illuminate patterns over time without forcing behavior change.
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.
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
Support
Contributing
Lockstep is GPL v3 licensed. Contributions welcome. Tested on macOS, Windows 11, and Linux.
# 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/ -vCheck open issues for good places to start.
License
GNU General Public License v3.0 — Copyright (C) 2025-2026 Jack Daniel Williams / Dandelion Rose Group, LLC
Built as part of Dandelion Rose Group's mission to prove that neurodivergent minds are uniquely wired for AI partnership.
Available Tools
42 toolsadd_chain_linkBDestructive
Add a new session link to a chain. Auto-increments link_number.
Inputs: params (required). Returns: result
archive_chainCDestructiveIdempotent
Move completed chain to archive with retention metadata.
Inputs: params (required). Returns: result
branch_chainBDestructive
Fork chain when work splits. Parent doesn't complete until all branches do.
Inputs: params (required). Returns: result
check_chain_healthBRead-onlyIdempotent
Detect stagnant/forgotten chains. Always active regardless of capacity_tracking.
Inputs: params (required). Returns: result
check_stagnationBRead-onlyIdempotent
Evaluate if any role has hit its stagnation threshold.
Stagnation = active engagement but no growth. Dormancy = no engagement at all. Both surfaced as observations, not errors (Design Principle 2).
Inputs: params (required). Returns: result
close_ticketBDestructiveIdempotent
Close ticket. Advisory: flags if associated chain is incomplete.
Inputs: params (required). Returns: result
cmd_bug_fixBDestructive
Create bug-fix ticket. Optionally creates chain.
Pre-typed: Build -> Review (optional). Asks before creating chain
via create_chain parameter. If false, ticket exists for tracking
but no chain is created.
Inputs: title (required), description (required), entity, create_chain. Returns: result
cmd_enhancementBDestructive
Create enhancement: ticket + chain + planning declaration.
Pre-typed: Planning -> Architecture -> Build -> Review.
Starts in Planning.
Inputs: title (required), vision (required), entity. Returns: result
cmd_new_initiativeBDestructive
Create initiative: ticket + full-funnel chain + discovery declaration.
Pre-typed: full funnel (Discovery -> Research -> Planning ->
Architecture -> Build -> Review). Starts in Discovery.
Inputs: title (required), vision (required), entity. Returns: result
cmd_new_ticketBDestructive
Create a new ticket. Generic — human specifies everything.
If the ticket type triggers Lockstep threshold (not maintenance), returns a prompt suggesting chain creation. The Partner handles the conversational follow-up.
Inputs: type (required), title (required), tags, entity, +2 more. Returns: result
cmd_refactorBDestructive
Create refactor: ticket + chain + architecture declaration.
Pre-typed: Architecture -> Build -> Review.
Starts in Architecture. scope = "what's being refactored and why?"
Inputs: scope (required), title (required), entity. Returns: result
complete_chainADestructiveIdempotent
Mark entire chain complete. Lifecycle hooks per Decision 1.
Bug-fix/maintenance chains: auto-close associated ticket.
Other chain types: advisory suggesting ticket closure.
Inputs: params (required). Returns: result
complete_chain_linkCDestructiveIdempotent
Mark a chain link as complete, record deliverables.
Inputs: params (required). Returns: result
create_chainADestructive
Create a new chain from a ticket. Generates chain_id from kebab-case title.
Inputs: params (required). Returns: result
create_ticketBDestructive
Create a new ticket with auto-assigned sequential ID.
Inputs: params (required). Returns: result
get_capacity_eventsCRead-onlyIdempotent
Query capacity event history with optional filters.
Inputs: params (required). Returns: result
get_chain_statusCRead-onlyIdempotent
Lightweight status check: current link, phase, health.
Inputs: params (required). Returns: result
get_dashboardARead-onlyIdempotent
Aggregate view: active chains, open tickets, capacity summary, alerts.
First tool called every session — gives Partner the full operational
picture in one call.
Inputs: params (required). Returns: result
link_ticket_chainBDestructiveIdempotent
Associate a ticket with a chain.
If the chain already has an origin ticket (ticket_id) and the linked
ticket is different, the ticket is added as a child_ticket (Decision 2).
Inputs: params (required). Returns: result
list_chainsARead-onlyIdempotent
List all active chains (lightweight summary view).
Inputs: params (required). Returns: result
list_ticketsBRead-onlyIdempotent
List all open tickets.
Inputs: params (required). Returns: result
pause_chainBDestructiveIdempotent
Pause chain — preserves state, signals 'not abandoned'. Idempotent.
Inputs: params (required). Returns: result
promote_ticketBDestructive
Promote a standalone ticket into a chain (Decision 1).
Creates a chain from the ticket, scans for related tickets (same entity + overlapping tags), and returns candidates for nesting. Optionally nests specified tickets immediately.
Inputs: params (required). Returns: result
read_capacityBRead-onlyIdempotent
Read growth stage for a specific role or all roles.
Inputs: params (required). Returns: result
read_chainARead-onlyIdempotent
Read chain state filtered through progressive disclosure.
Early-phase chains show fewer fields to reduce cognitive load. Full data always accessible via direct YAML read.
Inputs: params (required). Returns: result
read_ticketBRead-onlyIdempotent
Read full ticket state.
Inputs: params (required). Returns: result
record_capacity_eventCDestructive
Log a capacity-relevant event with typed attribution (Partner's field notes).
Inputs: params (required). Returns: result
record_catch_eventCDestructive
Log Catch firing with qualitative capture.
Catch events firing = system working, not failure. The metric is
whether catches lead to better decisions, not whether they stop.
human_reasoning is optional but gold when present.
Inputs: params (required). Returns: result
record_gate_skipCDestructive
Log session-type leapfrog in chain metadata (Design Principle 1).
Partner flags, explains cost, asks — never refuses. The skip is recorded to enable pattern detection over time.
Inputs: params (required). Returns: result
record_handoffBDestructiveIdempotent
Write session-end handoff to chain link and data directory.
Captures decisions, files changed, open threads, emotional context, and next-session recommendation.
Inputs: params (required). Returns: result
record_session_declarationCDestructiveIdempotent
Write Session Declaration to current chain link.
6 components: type, goal, deliverable, completion criteria,
out of scope, partner confirm.
Inputs: params (required). Returns: result
rename_chainADestructive
Rename a chain: updates chain_id, renames YAML file, and fixes all cross-references.
Updates: chain file, ticket references, declaration files, handoff files,
catch files, and parent/child chain references.
Inputs: params (required). Returns: result
resume_chainADestructiveIdempotent
Resume a paused chain. Only valid from paused state.
Inputs: params (required). Returns: result
search_chainsCRead-onlyIdempotent
Search chains by entity, status, session type, date range.
Inputs: params (required). Returns: result
search_ticketsCRead-onlyIdempotent
Search tickets by type, entity, priority, status.
Inputs: params (required). Returns: result
set_chain_entityCDestructiveIdempotent
Tag chain with entity ownership (which subsidiary).
Inputs: params (required). Returns: result
set_chain_statusCDestructiveIdempotent
Update chain status with state transition validation.
Inputs: params (required). Returns: result
spawn_child_chainADestructive
Fork a chain when work needs a different type (Decision 5).
Type changes create child chains; parent retains its type and
history. spawn_reason is required — it's what makes cross-domain
ideation patterns researchable.
Inputs: params (required). Returns: result
tag_ticketBDestructiveIdempotent
Add or remove tags on a ticket.
Inputs: params (required). Returns: result
update_capacity_stageCDestructiveIdempotent
Record a stage transition (training-wheels -> partnership -> safety-net).
Inputs: params (required). Returns: result
update_chain_metadataCDestructiveIdempotent
General metadata updates: vision, entity, capacity_role, notes.
Inputs: params (required). Returns: result
update_ticketCDestructiveIdempotent
Update ticket metadata and/or append a note.
Inputs: params (required). Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 42 tools
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.
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.
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.
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
Related MCP Connectors
Cloud-hosted MCP server for durable AI memory
MCP server that lets your AI assistant build and deploy apps, hosting each one at a live URL.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
An MCP server that integrates with Discord to provide AI-powered features.
Related MCP Servers
- AlicenseBqualityDmaintenanceAn MCP server that gives AI assistants persistent memory across sessions. It stores project context, decisions, and progress in structured markdown files as well as a knowledge graph and sequential thinking for better memory storage.3625 npm1MIT
- FlicenseNot gradedqualityDmaintenanceAn advanced MCP server that gives AI assistants persistent memory with machine-learning-powered semantic understanding, enabling branching memory, semantic search, and project analysis.-
- AlicenseNot gradedqualityDmaintenanceA local MCP server that gives AI coding agents persistent memory and context across sessions.4 npmMIT
- AlicenseNot gradedqualityDmaintenanceA local MCP memory server that gives AI assistants durable project memory across coding sessions, storing context, changes, and decisions.1 npm1MIT