Contributing

1. Repositories
2. Local setup
3. Ground rules
4. Releasing (maintainers)
5. Security

Repositories

Repo	Scope
counterparty-core	domain, registries, risk engine, adapters, contract tests
counterparty-ai	AI risk research
counterparty-laravel	Laravel bridge
counterparty-bundle	Symfony bundle

Each is a standalone Composer package with its own tests and CI.

Local setup

git clone https://github.com/igorgawrys1/counterparty-core
cd counterparty-core
composer install
composer check     # php-cs-fixer + PHPStan max + Psalm level 1 + PHPUnit
composer cs:fix    # apply the coding standard

The ai, laravel and bundle packages depend on core (and bundle/laravel on ai). All are on Packagist, so composer install resolves them normally. To develop against a local checkout of core, add a path repository to the dependent’s composer.json:

"repositories": [{ "type": "path", "url": "../counterparty-core" }]

Ground rules

• Keep composer check green. PHPStan at level max (larastan / phpstan-symfony on the bridges), Psalm at error level 1.
• Never weaken a static-analysis baseline to make an error pass - fix the code.
• Add tests. Domain logic is unit-tested; external APIs are mocked (no live network). New registry drivers must pass RegistryDriverContractTestCase.
• English for code, comments, docblocks and commit messages; conventional commits.
• Target PHP 8.2+, strict types everywhere.
• The AI subsystem stays advisory: every claim grounded in a tool source; bump RiskPromptBuilder::VERSION when prompts change.

Releasing (maintainers)

Each package repo carries a Release GitHub Actions workflow (.github/workflows/release.yml) that fires on a v* tag. Publishing a version is therefore just:

1. Add a ## [0.1.x] section to that package’s CHANGELOG.md.
2. Tag and push: git tag v0.1.x && git push --tags.

The workflow then, automatically:

• creates a GitHub Release whose notes are the matching CHANGELOG.md section, and
• calls the Packagist update API so the new version is indexed immediately.

Deploys are authenticated with two repo secrets, PACKAGIST_USERNAME and PACKAGIST_TOKEN (a Packagist API token). Rotate the token in the Packagist profile and re-set the secret with gh secret set PACKAGIST_TOKEN --repo <owner>/<package> if it ever leaks.

Keep the ^0.1 constraints aligned across the dependent packages when they move together.

Historical: before publication the dependent repos resolved core/ai from private GitHub repos via repositories: { type: vcs } and a CI COMPOSER_AUTH secret. Both were removed once the packages went public on Packagist.

Security

Report vulnerabilities privately (see each repo’s SECURITY.md) - do not open public issues for security problems. Never commit secrets; .env is git-ignored.