Contributor Path

This is the shortest supported route from a clean checkout to a focused Komms change. It does not grant release authority and does not require signing keys, store accounts, service credentials, production infrastructure, every platform SDK, or the complete publication matrix.

1. Choose one bounded target

List the checked-in profiles:

python3 scripts/contributor-check.py --list

Then dry-run one profile to see its exact commands and owned paths:

python3 scripts/contributor-check.py --dry-run protocol

The available profiles are:

Run the selected profile before opening a pull request:

python3 scripts/contributor-check.py PROFILE

The profile runner removes signing/provider credential variables from child processes and rejects history-changing, publishing, registry-changing, and remote-login commands. It never pushes, tags, signs, packages for publication, uploads, merges, or releases. The source-controlled profile is the reviewable contract; do not replace it with an opaque local wrapper in an evidence record.

2. Pick a reviewable issue

An issue labelled good first change must name:

1. one concrete user or maintainer problem;
2. the exact in-scope and out-of-scope paths;
3. observable acceptance criteria;
4. the recommended contributor profile; and
5. whether a sensitive-surface owner must review it.

help wanted means the scope is accepted but may require more project context. accessibility, localization, documentation, tests, and the platform labels describe the kind of work. They do not override security-sensitive or protocol-compatibility.

Use the repository's “Good first change” issue form for a new bounded proposal. Before implementing an existing issue, comment that you intend to work on it so duplicate effort is visible. Assignment is coordination, not exclusive ownership.

3. Orient by dependency direction

The compact path is:

kult-crypto
  └─> kult-protocol + kult-store
        └─> kult-transport + kult-node
              └─> kult-ffi / kultd
                    └─> desktop / Android / iOS shells

The authoritative boundaries are Architecture and the Implementation Guide. Shells present typed core state; they do not invent protocol, trust, delivery, or storage semantics. Deterministic cross-layer fixtures live in fixtures/. Extend an existing versioned fixture when the contract already has one; introduce a new fixture only with a documented owner, bound, compatibility meaning, and consumer test.

4. Sensitive review boundaries

The following changes require the recorded owner in CODEOWNERS, even when the diff is small:

• cryptography, protocol codecs, canonical limits, trust, and downgrade rules;
• storage sealing, migrations, backup/recovery, and atomic transitions;
• admission, discovery, mailbox custody, rendezvous, wake, or provider policy;
• FFI/RPC compatibility, release workflows, signing, dependencies, or evidence validators;
• security/privacy claims, the threat model, accepted ADRs, governance, licensing, incident handling, or publication controls; and
• localization of recovery, safety-number, authority, consent, blocking, delivery-state, or security-warning copy.

Do not weaken a bound or error path to make a test pass. A behavior or wire/state change needs the applicable ADR/spec update before implementation. Suspected vulnerabilities use the private route in SECURITY.md, not a public issue containing exploit or secret material.

5. Pull-request handoff

Keep one concern per pull request. The template asks for:

• the problem and intentionally excluded work;
• the contract or issue it implements;
• the selected contributor profile and any narrower focused checks;
• user-visible, compatibility, privacy, and accessibility effects;
• deterministic fixture changes; and
• every unrun or externally blocked check.

An ordinary contribution does not need the full release matrix. A maintainer may request broader checks when a shared contract changes. Only an explicitly authorized publication candidate runs the complete local release gate, and only maintainers publish.

6. Troubleshooting

Ask in the issue when the failure remains ambiguous. Include OS, architecture, toolchain version, selected profile, exact failing command, and redacted output; never include credentials, keys, recovery material, contact data, or message content.