Submitting and review

My submissions lists yours a page at a time (25, 50 or 100), newest change first or by name, with a link for each status you have and its count; archived ones only under Archived. Search by part of the item's name, or pick a type; both show as chips, and the status links keep your sort and page size.

Withdraw is on your own submission until it's released: as a draft, pending review, sent back for changes, or approved. It's in the header of its page, on its row in My submissions, and on its review page. A released version can't be withdrawn; deprecate or yank it instead. Withdrawing asks what to do with it:

• Archive (the default): it leaves review and My submissions' list. Only you see it, under the Archived filter. Restore brings it back as a draft, with its files, revisions and conversation; the next submit is its next revision.
• Delete for good: it's removed with its files and history, and can't be undone. It's offered only while no reviewer has commented on it or decided it; after that the conversation is a record for reviewers too, so it can only be archived. An archived one can be deleted the same way, from its page or the Archived filter.

Either way, the name is free: an archived submission, like a draft, doesn't hold it. What depends on it is marked blocked while it's archived, and not submitted once it's deleted. The audit log keeps a record of every deletion.

A draft can be saved with problems, but submitting waits until there are none. In the editor, a red icon after a file's name means it has errors, and an amber one only warnings: click it to see them, and click one to go to its line. The summary next to the item's name counts them all. Submit for review stays off while there are errors or unsaved changes (marked ● Unsaved changes beside the name). The submit dialog then checks:

• the manifest and files are valid for the type, and within the size limits;
• the name is free: no published item, and no open submission by someone else, uses it;
• each dependency is allowed for the type, and is released with a matching version, or is in review: then its version is checked when this one is released. A dependency that's only a draft doesn't count yet;
• for a change proposal: the type is the item's, it changes something, and no rebase conflict is left open.

A draft with none of these problems is ready. My submissions marks each draft Ready, or how many problems are left to fix, and submitting many at once takes only ready ones. Warnings are shown but don't stop it.

On My submissions, each draft, and each one sent back for changes, has a checkbox when it's ready. Tick the ones you want, or Select all ready, then Submit selected: it lists them and asks first, then submits each on its own and says what happened to each. A draft that stopped being ready in the meantime, because someone else submitted the same name, says why, and the others still go. Select all ready takes every ready draft, also those on other pages or hidden by a search.

From a terminal, with rmk:

rmk submit --all --dry-run          # what's ready, and what's in the way of the rest
rmk submit @team/reviewer @team/style
rmk submit --all                    # every ready one, after asking

• An item's name means your open draft of it; with more than one, name it by the id in its address. --all means every draft of yours and every one sent back for changes, the newest 100 at a time.
• It checks first, shows Ready to submit and Not ready with each problem, and asks. Without a terminal it needs --yes.
• It exits 0 when everything you named was submitted, and 1 when anything wasn't.

From your AI tool, the registry MCP server does the same: check_drafts shows what's ready, and submit_drafts, which your tool asks you about, submits it.

Your own drafts that a selected one depends on are included, and go first: once they're in review, what uses them can be submitted. Ticking a draft on My submissions ticks them too; rmk submit lists them under Included, and --no-deps leaves them out. What happens next is in Dependencies in review.

Reviewers can approve many at once too: Approving many at once.

A submission can depend on items that aren't released yet, as long as they're in review: a skill and the agent that uses it go through review together, rather than one round each.

• Waits on: in My submissions and the review queue, a link icon with a count marks what a submission waits on: amber while its dependencies are pending, red when one is blocked; click it to see each. The review page says it in full, such as Waits on @team/github (in review). In the editor, each dependency has an amber badge beside its name until it's released, and a red one if it's blocked.
• Approving doesn't wait: each item gets its own review, and reviewers see the mark.
• Releasing does: Publish stays off until every dependency is released, and the version range is checked against the version it got. Release the dependencies first.
• Blocked: when a dependency is rejected or archived, what depends on it is marked blocked, also further down a chain. Remove it from dependencies, or depend on another item. A new submission of the same name unblocks it.
• Rejecting a dependency: the reject dialog lists what depends on it and offers Request changes on them too, on by default, with a message of their own. Each is its own decision, recorded with the rejection as its cause. A moderator's own is skipped and named. Withdrawing your own says how many depend on it.

Reviewers find submissions under Reviews, in four tabs: Needs review and Waiting on the author (oldest submit first), To release (oldest approval first) and Decided (newest first). Every tab pages, 25, 50 or 100 at a time, with the total. Sort by the tab's time or by item name from the column headers, and find submissions by part of the item's or the author's name, or by type; filters show as chips.

For each submission, reviewers read:

• What it can do: risk flags worked out from the files, such as a hook and the command it runs, an MCP server, permission rules, executable files, shell scripts and web addresses. The author can't set or hide them. Flags describe; the reviewer decides.
• The changes since the last revision, or every file on the first one, as the item page shows a version's: the files in a tree beside the one you pick, each changed file marked added, changed or removed, Markdown rendered with its source a tab away. A risk flag's link opens its file at its line. Files in .ronne/, such as a canvas's layout, aren't released, so they aren't shown.
• The checks, and the conversation with the author.

• Approve: one approval by a moderator or root who isn't the author is enough. It's for the revision you're looking at: if the author submits a new one meanwhile, the approval doesn't go through, and you look at the new revision first.
• Request changes: it goes back to its author, with what to fix. An approved submission can be sent back too, until it's released.
• Reject: it's closed, with the reason. When other submissions depend on it, the dialog lists them and offers to request changes on them too (see Dependencies in review).
• Override: root may approve their own submission. It's marked as an override in the conversation and the audit log, with or without a reason.

Approving, the override included, takes an optional message. Request changes and reject need one, so the author knows what to fix, or why it was closed: they see it at the top of their submission's page, and under its name in My submissions. Every decision is recorded in the conversation and the audit log.

Where they are: on Reviews, each row of Needs review ends with Request changes and Reject, and each row of To release with Request changes. All the decisions are in the header of a submission's review page, which its name opens. Approving several at once is Approve selected.

Your own submission: the decisions show, but greyed out: another moderator or root decides. Root also gets Approve (override) on its own. A proposal that needs a rebase can be sent back or rejected, but not approved until it's rebased.

On Reviews, in Needs review, each submission you can approve now has a checkbox. Tick the ones you want, or Select all, then Approve selected. Select all covers the page you're viewing: show 100 a page, or filter first, to approve more at once.

• Some can't be selected, and their checkbox says why: a moderator's own submission (another reviewer approves it), or a stale change proposal, which its author rebases first.
• In the confirmation, the list scrolls on its own: filter it by name, type or author, and untick any you want to leave out.
• The confirmation lists them with the ones that have risk flags first, each flag named, so nothing risky goes by unseen. Root's own are marked: they're approved as overrides.
• One optional message goes on every approval, as if typed on each page. Leave it empty for none.
• Each is approved on its own, and recorded as a normal approval in its conversation and the audit log. One that was decided by someone else, withdrawn or went stale in the meantime is reported, and the others are still approved.

Request changes and reject stay one submission at a time, since each needs its own message: each row has them. Releasing is still done from each approved submission.