Harden core trust boundaries and delivery reliability

.github/CODEOWNERS

@@ -0,0 +1,17 @@
+# Current review routing. This file does not by itself provide independent review.
+* @AndriGitDev
+
+# Security- and compatibility-sensitive surfaces remain founder-owned until
+# qualified maintainers are recorded in MAINTAINERS.md.
+/crates/kult-crypto/ @AndriGitDev
+/crates/kult-protocol/ @AndriGitDev
+/crates/kult-store/ @AndriGitDev
+/docs/02-threat-model.md @AndriGitDev
+/docs/04-cryptography.md @AndriGitDev
+/docs/adr/ @AndriGitDev
+/docs/29-stabilization-program.md @AndriGitDev
+/.github/workflows/ @AndriGitDev
+/CODE_OF_CONDUCT.md @AndriGitDev
+/GOVERNANCE.md @AndriGitDev
+/MAINTAINERS.md @AndriGitDev
+/SECURITY.md @AndriGitDev

CODE_OF_CONDUCT.md

@@ -0,0 +1,51 @@
+# Code of Conduct
+
+Komms exists to make private, resilient communication useful to ordinary
+people. The community should be safe for contributors and users with different
+backgrounds, abilities, identities, locations, and levels of technical
+experience.
+
+## Expected behavior
+
+- Treat people with respect, patience, and good faith.
+- Critique ideas, designs, claims, and code with evidence; do not attack people.
+- Welcome questions and make room for less experienced contributors.
+- Respect privacy, consent, embargoed security information, and personal
+  boundaries.
+- Disclose conflicts that could affect a project decision.
+- Accept a moderator's reasonable direction and repair harm where possible.
+
+## Unacceptable behavior
+
+Harassment, threats, stalking, discriminatory language, sexualized attention,
+doxxing, deliberate exposure of private or embargoed information, sustained
+disruption, and retaliation against a reporter are not acceptable. Using the
+project to facilitate surveillance, abuse, or targeted harm is also outside
+this community's purpose.
+
+This policy applies in repository spaces, project communication, events, and
+public situations where someone is representing Komms.
+
+## Reporting
+
+Report conduct concerns privately to **andri@andri.is** with the subject
+`[Komms conduct]`. Include links or context, the impact, and any immediate safety
+need. Do not open a public issue about a private conduct report.
+
+Reports will be acknowledged promptly and handled with the minimum disclosure
+needed to investigate. The person named in a report will not decide the case.
+If the lead maintainer is involved or no unconflicted maintainer is available,
+the project will seek a mutually acceptable independent reviewer. Confidentiality
+cannot be absolute when action is required to prevent imminent harm, but the
+reporter will be told before broader disclosure whenever safely possible.
+
+## Enforcement
+
+Responses are proportional to context, impact, pattern, and willingness to
+repair harm. They may include a private correction, warning, content removal,
+temporary participation limits, or a permanent ban. Serious threats, doxxing,
+or retaliation may result in immediate restriction.
+
+The decision and any appeal are documented privately, with a public process
+summary when useful and safe. An affected person may appeal to an unconflicted
+maintainer or the independent reviewer used for the case.

CONTRIBUTING.md

@@ -2,9 +2,17 @@
 
 Komms 0.3 Alpha is a packaged public prerelease. Its core, transports, local
 RPC/CLI and UniFFI surfaces, and desktop/Android/iOS shells are implemented,
-while hardware qualification, production-signed/store distribution, broader
-hardening, and explicitly design-gated programs remain. Testers can start with
-the [Alpha testing guide](docs/27-alpha-testing.md).
+with automated evidence in many areas. Clean-install internet use, abuse
+admission, mailbox durability, hardware/device qualification,
+production-signed distribution, independent review, and other P0 gates remain.
+Testers can start with the [Alpha testing guide](docs/27-alpha-testing.md);
+current priorities and evidence language are in the
+[stabilization program](docs/29-stabilization-program.md).
+
+Komms is currently founder-directed, including intentional use of automated
+implementation assistance. Contributions provide ideas, implementation,
+testing, and evidence; product and release authority remains with the founder
+unless explicitly delegated.
 
 ## Where contributions help
 
@@ -17,9 +25,15 @@ Open an issue for anything in `docs/` that is wrong, unclear, or missing:
 - Disagreement with a recorded decision? Respond to the specific
   [ADR](docs/adr/README.md) and address the alternatives it already weighed.
 - Implementation work should start from the current gaps in the
+  [stabilization program](docs/29-stabilization-program.md). The
   [roadmap](docs/08-roadmap.md) and
-  [feature delivery plan](docs/12-feature-delivery-plan.md), then preserve the
-  relevant security, storage, compatibility, and carrier constraints.
+  [feature delivery plan](docs/12-feature-delivery-plan.md) are implementation
+  inventories, not permission to expand scope ahead of P0 work.
+
+Small documentation, test, accessibility, localization, and reproducibility
+improvements are welcome without first running the full release matrix. An
+issue is useful for design or ambiguous scope, but a focused, noncontroversial
+fix does not require advance permission.
 
 ## Implementation changes
 
@@ -31,27 +45,41 @@ Open an issue for anything in `docs/` that is wrong, unclear, or missing:
   crate boundaries, crypto coding standards, and review gates. Checked-in APIs
   are authoritative. PRs that change design without an ADR will be redirected
   to the ADR process, kindly.
-- Run the complete [local release gate](docs/24-local-release-gate.md): `fmt`,
-  warnings-as-errors `clippy`, all tests, `no_std`, dependency policy, generated
-  bindings/shell gates, and every fuzz target. Do not use hosted CI as an
-  interactive compiler; publication and any hosted repetition require explicit
-  maintainer authorization.
+- For an ordinary PR, run formatting plus the narrowest affected unit,
+  integration, clippy, and shell checks, and list exactly what ran. Reviewers
+  may request a broader check when a shared contract changes. The complete
+  [local release gate](docs/24-local-release-gate.md)—all targets, generated
+  bindings, fuzz smoke, dependency policy, and platform evidence—is required
+  for a publication candidate, not every contributor edit.
 - Update the README/status table, affected design or feature contract, platform
   guide, and ADR index whenever behavior, requirements, compatibility, or a
   release gate changes. Documentation claims must distinguish automated build
   evidence from hands-on device or hardware qualification.
 - Keep PRs scoped to one concern; cite the spec section your change implements.
+- Automated assistance is permitted. The human submitter must understand and
+  take responsibility for the diff, verify that they have the right to submit
+  it, check license and provenance concerns, run the applicable tests, and be
+  able to explain and revise the result. Automated output is not independent
+  review.
 
 ## Process
 
 - **Issues** for design discussion; **PRs** for concrete text/code changes.
 - ADRs follow [docs/adr/template.md](docs/adr/template.md) and appear in the
-  [ADR index](docs/adr/README.md); new ADRs are numbered sequentially and never
-  edited after acceptance (write a superseding one).
+  [ADR index](docs/adr/README.md). New ADRs are numbered sequentially.
+  Normative decisions in an accepted ADR change through a superseding ADR;
+  factual corrections, security-boundary clarifications, and cross-reference
+  repairs may be made in place when they do not silently reverse the recorded
+  decision.
 - Be direct about problems and generous with people. Security arguments win on merit,
   not volume.
+- Participation follows the [Code of Conduct](CODE_OF_CONDUCT.md). Roles,
+  decisions, review requirements, and current ownership are documented in
+  [GOVERNANCE.md](GOVERNANCE.md) and [MAINTAINERS.md](MAINTAINERS.md).
 
 ## Licensing of contributions
 
-By contributing you agree your contribution is licensed under [AGPLv3](LICENSE), the
-project license. No CLA: the license is the agreement, symmetrically, for everyone.
+By submitting a contribution, you represent that you have the right to submit it
+and agree that it may be distributed under [AGPL-3.0-only](LICENSE), the
+project's software license. No contributor license agreement is currently
+required.

GOVERNANCE.md

@@ -0,0 +1,119 @@
+# Komms governance
+
+Komms is founder-led by design during construction and stabilization. Founder
+Andri holds final product, technical, merge, release, and delegation authority
+while directing implementation toward a stable, polished, broadly capable
+messenger. This is not a claim of independent oversight. Governance may evolve
+when sustained adoption produces a real community capable of carrying
+responsibility; no date, reviewer count, or maintainer count automatically
+transfers authority.
+
+Komms has a nonprofit public-benefit mission. The project and every service it
+operates or designates as an official default must advance broad access to
+private, resilient communication. Revenue or surplus supports infrastructure,
+maintenance, security, accessibility, development, and reasonable compensation
+rather than private profit distribution. This is a project policy, not a claim
+of registered-charity or tax-exempt status, and it does not restrict the AGPL
+rights of independent operators, including commercial use. The complete
+decision is [ADR-0033](docs/adr/0033-nonprofit-founder-stewardship.md).
+
+## Roles
+
+- **Lead maintainer:** accountable for product direction, delegation, merge and
+  release authority, and the integrity of public status claims.
+- **Maintainer:** owns a documented area, reviews changes, and helps operate the
+  project. Appointment and removal are recorded in
+  [MAINTAINERS.md](MAINTAINERS.md).
+- **Qualified reviewer:** supplies scoped technical, security,
+  interoperability, accessibility, or operational evidence independently of
+  the implementation authorship. Review does not grant product-direction,
+  merge, release, or veto authority unless the founder separately delegates a
+  documented maintainer role.
+- **Contributor:** anyone who improves code, documentation, testing, design,
+  research, translations, or issue reports under the project contribution
+  terms.
+
+Current people and unfilled responsibilities are listed in
+[MAINTAINERS.md](MAINTAINERS.md). The lead maintainer is accountable for an
+unfilled area until it is explicitly delegated.
+
+## Decisions
+
+Issues and pull requests are the ordinary public decision record. Material
+changes to protocol compatibility, cryptography, identity, trust boundaries,
+storage formats, optional-service boundaries, or governance require an ADR or a
+documented governance proposal before implementation.
+
+Accepted ADRs are normative until superseded by a later ADR. Maintainers should
+state the user problem, alternatives, security and privacy consequences,
+migration plan, and evidence required for acceptance. Rough consensus is
+preferred; the lead maintainer makes the final decision and records the
+reason when consensus is not possible.
+
+Founder-directed automated assistance is an intentional implementation method.
+Automated systems are tools, not maintainers, reviewers, or decision-makers.
+The human maintainer remains accountable for provenance, scope, review, testing,
+acceptance, and public claims. Tool-assisted output is not independent review or
+release evidence by itself.
+
+## Review and release
+
+Every accepted change requires accountable approval by an owner for the affected
+area. During the single-maintainer Alpha the founder may author and approve a
+change, with that lack of independence disclosed. Changes to cryptography,
+authentication, identity, wire formats, storage migrations, release signing, or
+optional-service trust boundaries require two qualified reviewers, including
+one who did not author the change, before a stable release.
+
+While those reviewers do not exist, the project may continue clearly labelled
+Alpha research and testing, but it must not describe the affected work as
+independently reviewed, audited, or stable. CODEOWNERS routes review requests;
+it is not evidence that independent review occurred.
+
+External review substantiates assurance claims; it is not shared product
+governance. Reviewers may publish findings and decline to provide a positive
+assurance statement. The lead maintainer decides product disposition and
+release timing, but unresolved findings remain visible in the evidence ledger
+and cannot be represented as closed, audited, or independently approved.
+
+The lead maintainer currently authorizes releases. A stable release also
+requires all applicable P0 gates in the
+[stabilization program](docs/29-stabilization-program.md) to be closed with
+published evidence.
+
+## Conflicts, conduct, and appeals
+
+Maintainers disclose financial, employment, close personal, or competitive
+interests that could reasonably affect a decision and recuse themselves where
+appropriate. A person whose conduct is being reviewed does not decide that
+case. If no unconflicted maintainer is available, the lead maintainer will seek
+a mutually acceptable independent reviewer and document the process while
+protecting reporters' privacy.
+
+Project participation follows the [Code of Conduct](CODE_OF_CONDUCT.md).
+Technical decisions may be appealed with new evidence in the original issue or
+through a superseding proposal. Conduct decisions may be appealed privately to
+an unconflicted maintainer.
+
+## Security and operator independence
+
+Vulnerabilities follow [SECURITY.md](SECURITY.md), including coordinated
+disclosure. No project-operated bootstrap, mailbox, rendezvous, wake, update, or
+other service may become the authority for a user's identity or receive message
+plaintext or identity private keys. Operational convenience does not override
+the architectural boundaries in the stabilization program.
+
+## Succession and evolution
+
+Release credentials, domains, package identities, and incident procedures
+should have documented recovery and at least one authorized backup steward
+before a stable release. A temporary steward may maintain security and release
+continuity when the lead maintainer cannot act; permanent authority changes
+must be publicly recorded.
+
+Governance evolution is not automatic. When sustained adoption has produced a
+real community of users, contributors, reviewers, and operators, the founder may
+publish a proposal for additional delegated maintainers, a foundation, a
+steering body, or another accountable structure. Any transfer of authority must
+be explicit, public, mission-preserving, and proportionate to the community that
+actually exists.

MAINTAINERS.md

@@ -0,0 +1,70 @@
+# Komms maintainers
+
+Komms currently has one human maintainer. This is an intentional
+founder-directed model during product construction and stabilization. It also
+creates continuity and independent-assurance gaps that the project reports
+honestly.
+
+## Current maintainers
+
+| Person | Role | Areas | Contact |
+|---|---|---|---|
+| Andri (`@AndriGitDev`) | Founder and lead maintainer | Product direction, merge, release, security coordination, and all unassigned areas | `andri@andri.is` |
+
+The lead maintainer is accountable for final decisions under
+[GOVERNANCE.md](GOVERNANCE.md). Being listed as code owner or maintainer does
+not make self-review independent.
+
+## Contribution and review needs
+
+The project welcomes implementation help and qualified evidence in these areas.
+These are contribution and assurance needs, not vacant shares of product
+authority. Maintainer authority is delegated explicitly by the founder after
+sustained, dependable participation:
+
+- cryptography and protocol security;
+- discovery, NAT traversal, mailboxes, and radio transports;
+- Android and mobile lifecycle;
+- iOS and mobile lifecycle;
+- desktop, product accessibility, and localization;
+- release signing, reproducibility, updates, and incident response;
+- community stewardship, documentation, and contributor experience;
+- independent security review and interoperability testing.
+
+An interested contributor should open a public issue describing the area,
+relevant experience, and work they would like to contribute. Security-sensitive
+background details may be sent privately using [SECURITY.md](SECURITY.md).
+
+## Implementation assistance
+
+The founder intentionally uses automated analysis and implementation tools.
+Those tools are not maintainers, reviewers, or independent evidence providers.
+Every accepted change remains attributable to and the responsibility of the
+human maintainer who approves it.
+
+## Appointment and expectations
+
+Maintainers are appointed by the lead maintainer after a record of constructive
+contributions and dependable review in the relevant area. Maintainers are
+expected to:
+
+- follow the Code of Conduct and disclose relevant conflicts;
+- review within their demonstrated expertise and say when external review is
+  needed;
+- keep status and evidence claims accurate;
+- document material decisions and compatibility consequences;
+- protect embargoed reports, release credentials, and contributor privacy;
+- arrange a handoff or step down when they can no longer provide sustained
+  coverage.
+
+Appointments, responsibility changes, leaves, and removals are made by pull
+request to this file. The reason for an involuntary removal is recorded unless
+privacy or safety requires a narrower disclosure.
+
+## Review coverage
+
+[`.github/CODEOWNERS`](.github/CODEOWNERS) records current review routing.
+Areas with only the founder listed still have a bus-factor and independent
+assurance gap; they do not imply unassigned product authority. The release
+evidence must name the actual author and reviewers; a platform approval or
+CODEOWNERS match alone is not review evidence.