NAOMS can host a git repository inside a group of people you trust, and move changes into it through reviewed merge requests. No central code-hosting site sits in the middle.

What it is

A hive is a group of people who share things and make decisions together. A repository in NAOMS lives under a hive, so the hive's members are the natural people to review and land your work.

Your files stay in an ordinary git working copy on your machine. NAOMS keeps a signed, tamper-evident record of who the repository is, who may work on it, and what was decided.

A merge request is a proposal to bring one branch into another, usually a feature branch into main. Opening one leaves a visible, attributable record.

Who it is for

Builders: people who write code and want to review and land it among peers, including AI agents working next to them. If you already use git, you keep using git. NAOMS adds identity, membership and a review path around it.

A walk-through

Imagine Dana, who builds small tools and shares a hive with two collaborators.

1. Register the repo. In her project, Dana runs naoms repo add. Prefer the app? The Repositories tab has a "Register Repo" button. Starting from nothing, naoms repo init creates and registers a new repository in one go.
2. Bring in people. A member invites a collaborator, and the collaborator accepts.
3. Propose a change. On a feature branch, Dana runs naoms mr open with a description in plain prose. Status and logs views show what happened to it.
4. Let the checks run. The repository's pipeline runs against the change. A teammate with approval authority grants or rejects it. Opening a request does not grant it: submitting and approving are separate acts by separate roles.
5. Tag a release. naoms repo tag create records a release tag, which can start pipelines.

Checks you write in the repository

The checks live in .naoms/ci.yml, a plain file in the repository. A minimal pipeline names a trigger, such as a push to main, and a list of stages, each with a command, a timeout and a rule for what happens when it fails.

Check the file locally with naoms pipelines lint, then publish it with naoms pipelines update-yml.

One design choice matters for peer review: the merge gate reads its checks from the branch being merged into, so a change under review cannot rewrite the checks that judge it.

Why it matters

• One place for the record. Identity, members, proposals and decisions sit in one signed log.
• Review belongs to the group. Membership follows the hive.
• Agents and people use the same door. The merge-request verbs are also tools AI agents can call, with approval required for writes.

What's next

• Coming next: more proof across several devices. The repo package is marked stable, but no multi-device end-to-end test lives in it yet.
• Coming next: the pipelines package graduating from experimental as passing integration runs are recorded.
• Coming next: a richer app. merge-request work is done from the command line today.

Written by AI agents from real project logs; owned and edited by Mujo.