Skip to content

Contributing to ALP

Thank you for your interest in contributing to the Autonomous Lifecycle Protocol! This guide will help you get started.

Code of Conduct

By participating in this project, you agree to abide by the Contributor Covenant Code of Conduct.

How to Contribute

Reporting Bugs

Before creating a bug report:

  1. Check the existing issues to avoid duplicates
  2. Collect relevant information (version, OS, steps to reproduce)

Create a bug report with:

  • Clear, descriptive title
  • Steps to reproduce
  • Expected vs actual behavior
  • ALP version (alp --version)
  • OS and Node.js version

Suggesting Features

Feature requests are welcome! Please:

  1. Check existing issues and discussions
  2. Describe the problem you're solving
  3. Propose a solution with examples
  4. Consider backward compatibility

Pull Requests

  1. Fork the repository
  2. Create a feature branch (git checkout -b feature/my-feature)
  3. Make your changes
  4. Run tests (npm test)
  5. Commit with a clear message (git commit -m "feat: add my feature")
  6. Push to your fork (git push origin feature/my-feature)
  7. Open a Pull Request

Development Setup

Prerequisites

  • Node.js 24+ and npm 10+
  • Git
  • A code editor (VS Code recommended)

Clone and Install

bash
git clone https://github.com/Autonomous-Lifecycle-Protocol-ALP/Autonomous-Lifecycle-Protocol-ALP.git
cd Autonomous-Lifecycle-Protocol-ALP
npm ci

Build

bash
# Build all workspaces
npm run build

# Build specific workspace
npm run build --workspace @autonomous-lifecycle-protocol-alp/parser
npm run build --workspace @autonomous-lifecycle-protocol-alp/cli
npm run build --workspace @autonomous-lifecycle-protocol-alp/sdk

Run Tests

bash
# Run all tests
npm test

# Run tests for specific workspace
npm test --workspace @autonomous-lifecycle-protocol-alp/parser
npm test --workspace @autonomous-lifecycle-protocol-alp/cli

Project Structure

Autonomous-Lifecycle-Protocol-ALP/
├── parser/                  # TypeScript ALP parser
│   ├── src/
│   │   ├── parser.ts
│   │   ├── graph.ts
│   │   ├── loop.ts
│   │   └── ...
│   └── tests/
├── cli/                     # CLI tool
│   ├── src/
│   │   ├── commands/
│   │   └── index.ts
│   └── tests/
├── sdk/
│   ├── typescript/          # TypeScript SDK
│   ├── python/              # Python SDK
│   ├── java/                # Java SDK
│   ├── rust/                # Rust SDK
│   └── go/                  # Go SDK
├── mcp-server/              # MCP server
├── docs-site/               # Documentation
├── integrations/            # IDE integrations
│   ├── claude-code/
│   ├── cursor/
│   └── github/
└── sham/                    # SHAM IDE

Coding Standards

TypeScript

  • Use TypeScript strict mode
  • Follow Effective TypeScript patterns
  • Write tests for all new features
  • Use meaningful variable and function names

Python

  • Follow PEP 8
  • Use type hints
  • Write tests using pytest
  • Use docstrings for public APIs

General

  • Write clear, self-documenting code
  • Add comments only when necessary
  • Keep functions small and focused
  • Use descriptive commit messages

Commit Message Convention

We use Conventional Commits:

<type>(<scope>): <description>

[optional body]

[optional footer]

Types

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation changes
  • style: Code style changes (formatting, etc.)
  • refactor: Code refactoring
  • test: Adding or updating tests
  • chore: Maintenance tasks

Examples

feat(parser): add support for @timeline objects
fix(cli): resolve race condition in LockManager
docs(spec): update versioning section for v80.0.0
test(sdk): add integration tests for Go SDK

Testing

All contributions must include tests:

bash
# Run parser tests
npm test --workspace @autonomous-lifecycle-protocol-alp/parser

# Run CLI tests
npm test --workspace @autonomous-lifecycle-protocol-alp/cli

# Run Python SDK tests
cd sdk/python && pytest

# Run Go SDK tests
cd sdk/go && go test -v ./...

Documentation

  • Update docs-site/src/ for user-facing changes
  • Update JSDoc/docstrings for API changes
  • Add examples for new features
  • Update the changelog if applicable

Release Process

Releases are tagged with semantic versions:

  1. Update version numbers in package.json files
  2. Update docs-site/src/releases.md
  3. Create a git tag: git tag -a vX.Y.Z -m "Release vX.Y.Z"
  4. Push the tag: git push origin vX.Y.Z
  5. The publish workflow will handle the rest

Getting Help

  • M4 7V3a1 1 0 0 1 1-1h14a1 1 0 0 1 1 1v4M4 7h16M4 7l-2 4v6a1 1 0 0 0 1 1h14a1 1 0 0 0 1-1v-6l-2-4M4 11h16M10 15h4 Read the documentation
  • M2.84 5.16C1.82 6.18 1 7.5 1 9c0 4.42 3.58 8 8 8 1.38 0 2.69-.4 3.82-1.09l2.94 1.09a1 1 0 0 0 1.24-.54l1.52-3.78c.1-.26.14-.54.14-.82V7c0-2.76-2.24-5-5-5H7c-.55 0-1.07.15-1.5.42l.34.34z Join GitHub Discussions
  • M12 2a5 5 0 0 0-5 5v4a5 5 0 0 0 3.2 4.6V20h5.8v-5.4A5 5 0 0 0 19 11V7a5 5 0 0 0-7-4.9V2h2M9 6a3 3 0 1 1 6 0v3.1A3 3 0 1 1-3 6V7l-2-2 Report issues in GitHub Issues
  • M4 4h16c1.1 0 2 .9 2 2v12a2 2 0 0 1-2 2H4a2 2 0 0 1-2-2V6c0-1.1.9-2 2-2zm16 4l-2 1.5V6l2-2zm-4 3L10 12l-6-4V6l6 4 6-4v1z Reach out to maintainers via GitHub

Recognition

Contributors are recognized in:

  • Release notes
  • The documentation
  • GitHub contributors graph

Thank you for contributing to ALP!