From iPhone to Coding Session: Sven and Navigator
Six screenshots sent on the go become four tasks. How Sven, Navigator and session-orchestrator work, and what I still decide.
My iPhone shows me what I missed
On October 4, 2026, I am out and about when I send Sven six screenshots of my own website through Discord. On the iPhone, an arrow on the site turns into a blue emoji. I had not noticed it that way on the Mac. Some of the product copy also reads wrong on the small screen. My brief to Sven: review the copy and images, and improve them.
I don't need a terminal for that. I show him what I see. Whether the fix belongs in a component, an image or a sentence, I don't know yet. Sorting that out is Sven's first job.
I introduced Sven, the raven that works with me, in an earlier article. This one is about another part of our day. A message from my phone becomes work I can simply pick up at the Mac at home.
Sven turns the screenshots into four tasks
Sven checks the website rather than treating every complaint of mine as a bug. The blue arrow is a rendering bug. My dislike of a product description is a preference. Both deserve work, with different briefs. A bug needs the expected behaviour. A description needs me to say what the product should tell people.
The audit produces four tasks: copy, images, layout and editorial work. That beats one big “make the website better”. I can discuss each area on its own and decide which changes belong together. The screenshots show where the work started. The issues hold the findings.
Sven may create and comment on those issues. Pushing code, opening merge requests and merging are off limits. Research and creating tasks are routine I have already agreed to, so I don't approve every step.
What the brief doesn't answer, he has to ask. A screenshot shows him where to look. It can't tell him which direction I want a product to take. That is my call.
At home, Navigator watches the other sessions
At the Mac, I also need to see how a task fits into the work already running. That's why I built Navigator, my tool above the coding sessions. It runs as a lead session and takes over its predecessor's briefing. Then it looks across the fleet: which sessions are active, where, on what, and what goes first.
session-orchestrator works one level down. It takes a single session through planning, waves of work and checks. Navigator coordinates between sessions. The public session-orchestrator project is MIT licensed. Since October 5, Navigator has been on npm as lead-session-orchestrator, also MIT; its source repository stays private. On October 4, the local session-orchestrator package is at version 5.7.0.
Before a session writes anything, it checks in with Navigator. It gets conditions for its repository and its brief. One session might work on copy while another checks a separate area. Each has to know where its work ends.
For the four website tasks, this happened the same Sunday. A session on the Mac checked in, received its conditions and picked up Sven's audit. It clicked through the site again as the people it is meant for would, on desktop and on a phone. Then came the questions only I can answer. May the page open with the result instead of the method? Should businesses be addressed visibly? Which image direction? I answered, and it split the rest into parallel briefs.
The heavy checks get their own machine
Navigator also shares out scarce resources. Free memory sets how much can run in parallel. Work that starts processes gets different caps from work that only reads. As memory gets tight, fewer agents start, and eventually none. More open sessions would otherwise mostly give me a slower computer.
Heavy checks such as type checking, the full test suite, builds and browser tests are meant to run on a second Mac. If it is unavailable, the full merge-request pipeline on the exact code revision carries the check. A reachable computer is no proof that anything ran.
In Shipped, but never switched on, my October 15 article, I describe how long that second computer sat ready and unused. Today's conditions give offloading a place in the workflow. They don't prove past use, and I don't know yet how much time it saves.
For the website, that means I can review wording and presentation in peace while the expensive checks run elsewhere. The combined revision still gets checked at the end.
Before the merge, the session announces its revision
Inside a session, session-orchestrator organises work into waves. Changes are followed by the matching checks. If a check fails, the specific finding goes back to whoever owns that part. I described that bounded return path in Loop Engineering. A final “done” replaces neither the checks nor the agreed scope.
Before merging, there is one more handoff. The session announces the merge request, its head SHA, the pipeline and the diff. The head SHA identifies the exact code revision. Navigator can then check whether the passing pipeline belongs to the change about to be merged. And whether another session should go first.
Then it gives its signal for the order. This is where I keep message and permission strictly apart.
A message carries an instruction, not permission.
A forwarded approval still needs a valid source and has to cover this exact action. That authority comes from my mandate or a valid authorisation document. Navigator's signal cannot create it. After the merge, the result and any deployment are checked again.
For the screenshots from my iPhone, that was merge request !99. It brings a homepage that opens with the result. Plus new product cards with images, and this very article series. The session sent its announcement. Navigator checked whether another session was waiting ahead of it on main, and gave the signal. Only then was it merged, on exactly the revision the pipeline had checked.
The actual decisions come back to me
Open decisions go into the owner queue with options, a recommendation and a deadline. The queue decides nothing. It records what needs my answer and what I decided.
With product copy, that is the line between a writing task and a change of direction. Within the brief, a session can draft and check. If it wants to change what I say about a product, I want the question back with a proposal. I shouldn't have to read the whole conversation to find it.
The persistent connection between Sven and Navigator has not passed its operational acceptance yet. Delayed pickup, replies and handling duplicate messages are documented. I won't call that a continuously working autopilot.
The useful part is already here: what I send while I'm out survives as a checked task, and I carry on from there at home. The shared quota still needs work. Around midday on October 4, Navigator had to cut concurrency and move routine work to another model because the fleet was nearing the limit.
Common questions
What does Sven do with my screenshots?
He checks the website, separates bugs from preferences and creates tasks. He cannot push code, create merge requests or merge. Creating and commenting on issues is fine.
How do Navigator and session-orchestrator differ?
Navigator is my tool for coordinating multiple sessions. Since October it has been on npm as lead-session-orchestrator, MIT licensed, with a private source repository. The public MIT project session-orchestrator handles planning, waves and checks within one session.
Does a message from Navigator authorise a merge?
No. Its signal sets the order. Permission comes from my mandate or a valid authorisation document. It has to cover the specific action.