Initiative

Three lanesCopy Anchor Link

All three lanes share one project. Background investigation can run while you chat in the foreground; if you interject and steer elsewhere, the earlier investigation is kept as an open item.

On every nudge it picks one of fourCopy Anchor Link

• Wait: with no new evidence it makes no busywork and sends no status message. This is the most common correct answer.
• Work: investigate, change or verify within the authorized scope and budget.
• Share: speak when there is a new finding, when it needs your decision, or when it fulfils an earlier promise.
• Learn: turn a recurring correction into a rule and hand it to the evolution lane.

When it speaksCopy Anchor Link

There is no cap on how many times Rna may speak; each time the evidence decides. Between two proactive messages there is only a minimum interval (300 seconds by default, 30 seconds under the “active” rhythm preset, 900 under “quiet”). The factors below affect communication only, never the background work itself:

• Typing: while you type, proactive messages wait for a pause (the “Wait while typing” setting).
• Away and night: Rna learns your rhythm from when you send messages. Non-urgent messages wait while you are away or resting, and are merged into one “While you were away” message when you return, listing at most 5 topics with the rest filed in the inbox.
• Urgency: the main model gives each proactive message a tier. Your settings and the judge can only lower it, never raise it.

• Your reactions: a topic you keep ignoring needs more reason to come back; when you reply and resolve a proactive topic, it closes.

Background work that needs your decision comes back into the conversation, and one decision card asks only once. When several cards are above the composer, answering one shows the next.

Off, mute and quietCopy Anchor Link

Three controls, each doing one thing. They live in Settings → Autonomy & rhythm (under the “Advanced” group), and as /initiative or ./rna initiative:

resume ends a quiet period and makes sure initiative is on; it does not clear mute, which needs unmute. Neither mute nor quiet cancels an investigation.

The foreground goes firstCopy Anchor Link

While a foreground turn of yours is running, new background decisions wait for it to end; when the turn is waiting for your answer or authorization, the background can continue. A background run that can write but has no worktree of its own stops when you start a new turn and the turn carries on with it, and the conversation says so. Runs in their own worktree are not affected.

Background changes are not cancelled because you opened a new conversation, switched plan mode, changed model or credentials, or adjusted this project's capabilities. Only a change of project identity (the folder) or a narrowed background permission stops running work.

No repeated workCopy Anchor Link

Work the foreground had just checked used to be re-checked by the background right after, at a cost of hundreds of thousands of tokens each time. Now, after the main model decides to “work” and before anything is queued, JEV judges whether the work only repeats an existing check:

• does it only read files and run checks, writing nothing;
• is there a finished (or still running) run that examined the same files and the same behaviour;
• has anything relevant changed since.

When all three are clear, the work is not queued and the next decision can see why. If any one is uncertain, JEV is unavailable, or there is nothing to compare with, it goes ahead as usual. Before release it was tested on 19 labelled real situations and got all of them right.

Failed requests stay yoursCopy Anchor Link

If a question you asked in the foreground fails on that turn, it is still yours until you send your next message: the conversation offers “Retry request” using the model you chose. The background does not race to answer it with its own model, and does not send a message about the failure.

It knows what you rolled backCopy Anchor Link

When you roll back a turn, discard a subagent's changes or revert background changes, the background sees on its next judgment that “the user undid this on purpose”. It does not treat it as out of sync and propose putting it back. Rolling back does not itself wake the background. See Isolation and rollback.

CommitmentsCopy Anchor Link

Things Rna said “I'll do”, and requests you made, are recorded as commitments: what it is, what caused it, and what evidence there is. In short:

• The due time follows the facts. A commitment has no fixed due moment when created: your own deadline is used if you gave one; otherwise JEV judges from progress when to look again; with no judge service configured, it is a flat four hours.
• Done needs an outcome. A commitment that involves file changes is done only when those changes are applied to the project (or truly changed no file). If you roll back or discard the changes, the commitment reopens.
• Asking again does not duplicate. Asking for the same thing again joins the original commitment and restarts its window.
• Overdue means asking you. Above the composer: “You asked me to … and it is not finished. Shall I carry on?”, with “Carry on” or “No need”. The “What Rna learned” card on the project overview shows the number of open commitments and a link to overdue ones.
• It does not hang forever. A commitment with no sign of life for 14 days is marked expired.

When you delete a conversation or roll back a message, the pending commitments and open items that came from it end with it.

Scheduled resultsCopy Anchor Link

When a scheduled task runs on time, everywhere it is shown as “Scheduled task “name””, never exposing the internal instruction. What is delivered is the whole final report, not an excerpt; a long report arrives complete with the message.

Limits of background workCopy Anchor Link

• Background is read-only by default. Only when you explicitly choose “Use project permissions” does it inherit write and execute rights within the assigned capabilities. If it has stayed read-only while you repeatedly asked it to act, it asks once whether to open that up.
• Background commands run under macOS seatbelt: nothing is writable outside the project folder, temp folders and package caches; the project's .git is not writable, credential folders such as ~/.ssh and ~/.aws are not readable, and it cannot connect back to the daemon's own port.
• Background work with write rights snapshots every file it changes. A line in the conversation says how many files changed and offers one-click revert; revert does not by default overwrite files changed afterwards.
• In a Git repository, every background run works in its own worktree. If no worktree can be had, the run does not start and does not fall back to changing the project folder directly. While your own turn is still going, changes wait in the working copy and are applied when it ends; conflicting files keep the project folder's version; while your own git merge or rebase is in progress, applying waits for it to finish.
• A problem the background fixed directly shows a card asking whether to keep or revert it.

Controlling the backgroundCopy Anchor Link

./rna background PROJECT_ID                       # view background work
./rna background PROJECT_ID pause ACTION_ID
./rna background PROJECT_ID steer ACTION_ID --text 'Check the official sources first'

In a session: /initiative on|off|mute|unmute|quiet|resume and /background. The pace is set in Settings → Autonomy & rhythm: “Adapt to the project automatically” by default, or switch to manual and pick the “Active / Balanced / Quiet” preset; on the command line, ./rna frequency PROJECT_ID active|balanced|quiet.

Proactive messages Rna writes itself, the daily digest, “While you were away” and topic-close notes all use the interface language.