v1.2.29

Start, queue and run sprints side by side, from the cockpit. 95 pull requests merged, and this section covers all of them. On 1.2.28 the way to start a sprint as waves was on no screen, queueing from the cockpit did not work, a second start was refused without a word, back threw you out of Waves, and the waves widget counted only merged tickets and grew with every run. In 1.2.29 you can start a sprint as waves, queue one, or run a second beside the first: from the War Room, from Waves, or by telling ACE. Every Waves screen shows the next step, and when a key is refused, it says why and what to do, in place. Back takes you back. The waves widget shows what each run on it is doing, with the same symbols for one run or many, and turns its page instead of growing. Help on Waves and in the War Room is one short table of that screen's keys, and ACE can now stop or pause a run you name. F on a run fires its next wave now. The War Room and the Gantt lead with what is past due, each sprint's pace and how many tickets it closes a day. Keys that moved are listed at the end of the first section, each as what now works. The roster stays at 52; one specialist changed. What is not done yet is listed at the end, with the one limit the last check of this release found on the built binary.

Start, queue and run sprints side by side

• 🔴 Start or queue a sprint right from the War Room. On a sprint, on the list or on its board, S opens one choice over the War Room: start it now, add it to the queue, or see its waves. Two presses, S then enter, start it, and you stay on the same row. The row above the footer then says Started as run A. Watch it in Waves · Q. With the limit full, the choice starts on "Add to the queue" and also offers to raise the limit and start (#7712, #7710).
• 🔴 Add a sprint from the Waves overview. S acts on the row under the cursor. On a running row, or with no row, it opens Pick a sprint: the open sprints, read fresh each time it opens, filtered as you type. enter turns the pick into that sprint's choice. If the sprints cannot be read, the sheet says so and offers to try again (#7713).
• 🔴 Every door reads the sprints at the moment you act. The add form no longer shows "nothing to add" on an empty or held queue, Q on an open sprint no longer says it "is not open to add", and queueing no longer answers that a sprint "is not a milestone of this project" (#7701). A project picked from the project list reads its sprints and its initiatives on the first open, so the War Room no longer says "Initiatives didn't load" until a restart (#7706, #7790).
• 🔴 What is queued starts by itself, and you steer it from the cockpit. p on Waves lets the queue run or pauses it, and the band, the queue divider and every waiting row say which. On a stuck run, S offers to resume it, or to skip the ticket it stopped on after a confirm that names the ticket and the run. Settings ▸ Waves has a Queue switch that says why when the queue paused itself (#7714). One door does every queue move for the cockpit, the command line and ACE, so a move is checked the same way wherever you make it (#7705).
• Start now starts the sprint when there is room. Before this, right after the War Room refreshed, it could answer What runs now did not load and start nothing. A start that does not land now writes why to the cockpit's log (#7852).
• A merged ticket that waits for your sign-off no longer makes its run stuck. The run counts it as landed and goes on to the next wave; before this, a follow-up pull request naming the same ticket could stop the run after three tries (#7786).
• A run no longer refuses its own tickets. On a project picked from the project list, a run could refuse its own ticket hundreds of times a second and never begin its first wave. Now its slots are its own, a refused run waits before it tries again, and a run that cannot start a wave writes why to the cockpit's log, once (#7855).
• A second sprint runs beside the first in one decision. The choice names the limit once (Limit 1 — one sprint at a time · 0 running) and what each option will do (#7710).
• A refused start keeps its letter. Before this, each refused start used up a run letter, so the runs read A, then D. Now a start is checked before it is enrolled (#7702). A run started by ACE or the command line gets a letter like any other (#7718).
• Stop or pause any run from its row or its own screen, and stay where you are. With two runs live, X and P act on the run under the cursor; before this, every run but the first answered "runs elsewhere". The stop confirm names the run and the sprint, and the answer says what happened: Stopped run B. Work already going finishes. A run another cockpit drives says so. A stopped run now brakes only its own tickets: with auto-merge on, a reviewed, green pull request elsewhere on the machine merges as before (#7716, #7745).
• Fire a run's next wave now, from its row or its own screen. F asks that run to start its next wave at once; a paused run takes that one step and stays paused. When the next wave waits on an earlier one, F says so: Not fired — run B's next wave (≈2) waits for ≈1 to finish. With auto-merge off, a run's footer does not offer it (#7800).
• Every run the cockpit holds is a row on the Waves overview, including one started from the command line or by ACE (#7717).
• A second run's screen is about that run: its name in the frame, its tickets with titles, and its header in the same words as the first run's (#7715). The run detail is never a dead end: the keys walk the run on screen, a merge reaches every run that is waiting on it, and the breadcrumb names the run shown (#7742).
• Someone who has never started a run sees where to begin. One line, step 1 of 4 · Sprints start in the War Room, follows them through the first start, and stops once their first run is going (#7719).

Keys that moved, each as what now works (#7711, #7712, #7713, #7714, #7716, #7722, #7724, #7800):

• esc and q go back one level. Only the Waves overview leaves Waves, and it returns to where you opened it. Stopping a run, firing a wave or opening a ticket leaves you where you were (#7711).
• S on a War Room sprint starts or queues it. The behind / ahead filter moved to B, which cycles behind → ahead → off (#7712).
• Q on a War Room sprint opens Waves with that sprint's choice up, so Q then enter starts it (#7712).
• On Waves, S adds a sprint: S then 1 starts it beside the others, and S then 2 adds it to the queue. Pressed from habit, Q, R and a change nothing and answer with their new key, for example Q has moved. S, then 2, adds a sprint to the queue. (#7713, #7724).
• On a sprint's board in wave mode, Q opens Waves on that sprint. L answers with its new key (#7724).
• p on Waves pauses the queue or lets it run (#7714).
• X and P stop or pause the run under the cursor, on its row or its own screen (#7716), and F there fires that run's next wave now (#7800).
• < and > turn over the runs on Waves, where tab still works. On the cockpit home they pick the run the waves line shows (#7722).
• w opens Waves from the home footer at every width, 120 columns included (#7722).
• ? on Waves and in the War Room lists what moved under Moved in 1.2.29, at the end of that screen's keys (#7724, #7802).

The waves widget shows how each run is doing

• 🔴 Each run's row says how many tickets are working, waiting and merged, and which wave it is on. For example ▶ 1 working ⋯ 3 waiting ✓ 0 of 4 merged, beside wave ≈1 of 3. The main line is always one run, in the same words and symbols as its row. "Running" now means a run, and "working" a ticket; "stuck" replaces "parked" (#7720).
• 🔴 The widget keeps one height and turns its page instead of growing. With more runs than rows, the main line shows page 1 of 2, and the page turns by itself. A run that needs you is pinned to every page, and every run on the widget keeps its name, never just its letter (#7721).
• The widget lists every run the Waves overview lists, including one started from the command line or by ACE that has not fired its first wave yet, so its count matches the overview (#7853).
• The main line counts the tickets working across every run, for example 2 runs · 8 working, the same as the Workers panel, and a resumed run counts its whole sprint, tickets closed before it started included (#7851).
• You pick the run the waves line shows. < and > on the cockpit home move the line to the next or previous run, and it says by hand while your choice holds. A run that newly needs you takes the line once; when it is resolved, your choice comes back (#7722).
• A stuck run stays on the widget. Its row names the ticket it stopped on and the way on: w, then S: resume or skip · X: abandon (#7786).
• A stopped run no longer hides a live one on the waves strip. A stopped run the cockpit still holds no longer blanks the run beside it (#7731), and a stopped run's numbers are no longer painted again as running (#7752).

Every Waves screen shows the next step

• 🔴 The next step and the answer to a refused key are in the same place on every Waves screen, directly above the footer. The next-step line is one row, in every state: Queue paused. Nothing starts. Turn it on · p, Nothing needs you. Add a sprint any time · S. After a refused key, the answer says what did not happen and the one way on, and the next key clears it (#7708).
• 🔴 A refusal says what did not happen and what to do next, with no command and no "founder". A start refused by the limit names the limit and the live runs, and offers to raise the limit or to queue, never "stop the other run". The auto-merge refusal lost its ADR numbers (#7703).
• A sprint waiting in the queue says why in plain words: the limit is reached or the queue is paused, never "width", "held" or "Autorun". A stop or a give-up names the run: Stopped run A, Gave up run A (#7854).
• A waiting wave says waiting and what it waits for, in a WAITS FOR column (≈1 to merge), and a stopped run's footer offers X give up, with a confirm (#7866).
• Nothing on a Waves screen is cut from its middle. Each screen is built to the rows it has, at 80×24 too, and the queue editor shows one group of fields at a time (#7709).
• 🔴 ? shows that screen's keys in one short table, on every Waves screen and in the War Room, grouped by what each key acts on, and fits one screen at 120×40. ? again opens What marks mean: one line per mark, what it means and an example as the screen draws it. enter on the last row turns the first steps on or off (#7802).
• The Workers panel and ACE say it in plain words. The panel's title reads 3 of 9 workers · 3 here, a run's group reads A · <sprint> · ≈1 · 1 worker · 1 bug · merges into main, a ticket that waits reads waits for #7513, and ACE reports a start as Started <sprint> as run A. Wave ≈1 begins; later waves follow as tickets merge. (#7803).
• The War Room counts waves from 1 and names them plainly: Waves of <sprint> · 3 waves · ≈1: 1 ready, waits for ≈1, and a Waves mark that reads ▶ 1 running · 0 waiting · Q Waves (#7723).

Tell ACE

• 🔴 ACE finds the sprint you mean from a few words, by number or by the start of each word, with accents and dashes ignored. One match comes with its choices and keys, several come as up to five to pick from, and none comes with the closest. When the limit is full, ACE offers the fix (#7725).
• ACE does Waves with the same door as the cockpit, and teaches you the key. Ask it to start or queue a sprint, move or remove one, raise the limit, pause the queue, or resume or skip a stuck run: it tells you what happened in the product's own words and names the key that does the same on Waves. It never hands you a command to type (#7726).
• Ask ACE to stop, pause or resume a run by name: "stop run B", "pause the newsletter run", "resume #224". ACE asks before it stops, then says what happened in the cockpit's own words and names the key that does the same: X on the run's row stops it, P pauses or resumes it (#7801).

Behind, pace and velocity at a glance

• 🔴 The War Room leads with what is past due. Its band puts the tickets past due first, out of those still open, then the sprints behind, ahead and on track as tiles. Each sprint's strip adds its own past due, its pace, and how many tickets it closes a day, with a small chart of closes per day (#7515, #7885).
• 🔴 The Gantt's band is a row of cards: schedule in days, pace, tickets closed per day since the start with a small chart, progress, and how many tickets finished on time (#7516).
• Every number names what it measures, and the War Room and the Gantt compute it the same way. "Behind" counts sprints and "past due" counts tickets; velocity reads as tickets closed and closed per day since the start; a sprint due today reads the same number on both screens. The War Room says that Waves counts a ticket done when its pull request merged, and the War Room when it is closed (#7514).
• The War Room counts no ticket on track before its dates are read. The band says … dates not read yet instead of a number it cannot justify (#7513).

The epic as its own scope

• t on an ◉ EPIC row opens that epic's own Gantt. It shows the epic's own tickets across every sprint it spans, and never silently widens to the sprint (#5212).
• Groundwork for epics: one membership rule for an epic (#6155), the Gantt takes its scope from one typed value and every title names what it shows (#6154), the War Room board carries one typed scope and resets wave state when it changes (#6156), and an epic's roster can be read across its sprints (#6158).

The release, one yes

• 🔴 The cut asks its one yes last, after every machine gate has passed and the lane is proven green, and a red lane never reaches you. A cut that merged and then stopped resumes with no new yes. Main's CI wait is measured from the slowest suite, and a flaky suite gets one re-run and is reported (#7672).
• Answer the cut's yes where you are: F in the cockpit, the desktop app's band, or, as a fallback, a terminal (#7677).
• The cut's gating suites run every night on each active release lane, so a break shows the next morning, not on cut day (#7678).

Ratify and merge

• Ratify from the Documents drawer, with three outcomes: Ratify, Not yet with what is wrong (recorded, then sent to the pull request's worker), or close and record nothing (#7689).
• Open document lands in the drawer inside FlowForge Desktop, not in the system viewer (#7773).
• A ratified plan opens and fires from a cockpit on any branch. o on a plan's sprint opens its document, as a read-only copy when the cockpit is on another branch, and firing or queueing the plan reads it from its own release line instead of answering that it is not there (#7795).
• A merge waiting on your decision is held until you answer. Every merge door reads one record of your open decisions, auto-merge included (#7697).
• A reviewed pull request is marked ready on every review door, and the merge dialog recommends from the rows that failed instead of always asking for a review (#7682).

Steadier under the hood

• No test and no development build can write your settings file. A test had reset one account's parallel-worker setting (#7764).
• A live proof can no longer reach your running cockpit (#7696).
• The nudge stands down while a worker waits on your answer, and ACE's recap holds only on a known person block (#7767).
• A reviewed pull request that only needs its conflicts resolved can be rebased and pushed with no override; the push is checked against git, and a new review is still owed (#7766).
• The brief shows every answer option in full. The focused question's options wrap under their letter instead of being cut to one line, a question taller than the pane scrolls and says how much is left, and the brief uses a wide window (#7793).
• The queue editor's changes go through the same checks as every other queue move. If one change in an edit is refused, nothing in that edit is saved (#7806).
• Raising the limit from a sprint's choice is logged the same way as + on Waves, so the release check can see it (#7789).
• The 1.2.29 lane's gating suites are green, each red traced to the merge that caused it (#7869).
• TUI test runs wait in a short, ordered line, reviews first, instead of one long queue (#7734).
• The cockpit's CONTEXT clock stands above the gauge, not on it (#7680).
• Starting a session no longer rewrites a project's CLAUDE.md for its version stamp alone, and a merge no longer reports a worker in flight on a pull request that already merged (#7673).

Studies, records and groundwork

None of these change what you run. Each one is listed only as what it is.

• The Waves study that this release builds: the live audit of 1.2.28, the design and two plans (#7683). The shortest path for every Waves task, counted on 1.2.28 and on the 1.2.29 design (#7707).
• The journey test that every Waves change in this release turned green (#7699), and its replay on the built binary (#7700). The release check that replayed the whole journey on this release's candidate build, at four sizes and looks: its final run, on the build with every change above, holds 21 of its 22 steps, and what it found with many runs at once is the limit under Not yet (#7728). The kit for watching two people use Waves on the released build: a moderator guide, task cards and a report frame (#7729). The Waves panel's key file split to make room (#7704).
• A monthly letter anyone can read: the newsletter study's ideas and its plan, for the founder's approval (#7779). Every release letter now teaches two connected agents and one feature, with a picture for everything it talks about (#7774).
• The Waves manual, a PDF in English and Portuguese that teaches a plan, a first wave, a second wave and the queue, with real screens of this build (#7886).
• The release roadmap study: where a release stands and what is left, one key from the War Room and on the web; ideas and drawings for the founder's answers, nothing built (#7870).
• These release notes and the letter (#7730).
• A local record of how Waves is used, kept on this machine in ~/.flowforge/logs/waves-events.jsonl: which Waves screens open and close, and what each act on a run or the queue answered, by action name only. It never records a key press, typed text or what is on screen, and it has no network code (#7727).
• Two decisions written for the founder to answer: what a calm or a strong wave would set (#7805), and one meaning per letter for the War Room's own ticket keys, where nothing moves until it is ratified (#7804).
• Down-merges carried the v1.2.28 cut into the 1.3.0 line (#7674) and kept 1.2.29 and 1.3.0 in step; the second brought the past-due, pace and velocity work into 1.2.29 (#7876, #7884).

Agents — 52, unchanged in count: one specialist changed

• Changed fft-release-engineer — runs the cut so you give one yes, last: it proves the lane green before asking, relays the request for you to answer with F in the cockpit, the desktop band or a terminal, resumes a cut that merged and then stopped with no new yes, and files each flaky test it finds as a bug (#7672, #7677).
• New skill flowforge-waves, carried by ACE: it starts, queues and changes Waves, and stops, pauses or resumes a run you name, through the Waves tools and never through a command. It asks before it stops a run. It finds the sprint first, acts on the fix a refusal offers, relays what the product said, and names the key that does the same; a test fails if it names a tool or a key that no longer exists (#7726, #7801).

One setup step

• Quit and relaunch every open cockpit and FlowForge Desktop after you update, so the new Waves screens, keys and widget are the ones running.

Not yet

• The widget turns its page every 30 seconds for now. That time is provisional and will be set from what people need (#7721).
• With 6 or more runs at once, later runs can wait for a slot, and a run started from the command line may not begin (#7916, fixed in 1.2.30).

Update

• flowforge update on an existing install, or curl -fsSL https://get.flowforgesoft.com/install.sh | sh for a fresh one. Both write the same release binary to /usr/local/bin and ~/.flowforge/bin together. flowforge update --repair re-lays the installed assets without the network. Then quit and relaunch every open cockpit.