Modes and approvals

The modes

The mode decides what happens when you ask for a change. Questions are always just answered, in every mode.

Only Direct needs Git: it writes in your real files and keeps Git as the undo, so a wrong write can be taken back. Governed builds in a copy and needs none.

Choosing Direct in a folder with no Git (the mode buttons in the browser; tab, /mode direct or /mode auto in the terminal) asks at once, before anything is sent: Direct needs Git here. Set up Git now?

Asking for a direct change in a folder with no Git (/direct … or /do … in front of a message, Do it directly on a change offered in Ask only, or a session started in Direct) asks the same question in the conversation:

Nothing is made until you answer. A folder with more files than a first commit should carry (usually a dependency folder a .gitignore would leave out) is left as it was, and the answer says so.

Example. Open a folder of HTML files with no Git and click Direct: Direct needs Git here pops up. Choose Yes, set up Git: the folder gets Git with one commit, Baseline before the first direct change, and Direct is on. Ask Add a dark mode toggle; git diff shows exactly what Albert changed, and git checkout . undoes it.

Choose it:

The mode belongs to the session, so both interfaces show the same one.

Switching mode in the middle of a conversation

The mode counts from your next message, and Albert is told it every time, so you can switch whenever you like and say so in plain words:

If you ask for a change in a way the mode you are in does not work (just do it directly while in Governed, say), Albert says which mode does that and starts nothing; the change is offered under its reply with Plan it first and Do it directly, so you can press one, or switch and say go ahead.

Example. In Governed, Add a multiply(a, b) function to app.py comes back as a plan. Switch to Direct beside the box and send ok, do it directly: the plan is set aside and the function is added to your files.

The two human gates

In the Governed mode a change stops twice for you.

1 · The plan. Before anything is written: the goal, the files it will change and how, its tests and its risk.

2 · The result. After it was built and checked in the isolated copy, before anything reaches your files.

When the reviews block a change, applying it anyway asks for a reason, which is recorded.

Writes, in Direct · ask each write

Each write and each command waits for you, with what it changes:

A change offered, in Ask only

Either closes the question at once, and the proposal says it is starting while Albert reads the code; the steps show as they happen. If the change cannot start (no model connected, say), the proposal is offered again with a note saying why.

Answering

In the terminal, a gate is a question over the prompt with numbered answers: the arrows choose and enter gives the chosen one, or its number or letter does. In the browser it is a card with its answers in a row, and the same letters work. An answer given in one interface is seen at once in the other, and a task is never answered twice.

From scripts

albert-mini run sends one request and prints what happens. Gates are answered only as --approve says:

albert-mini run "add a health check endpoint" --approve plan,result

Without --approve, a governed change stops at its plan and exits with code 3. See Commands.