Help

When a system goes quiet, you cannot tell whether it broke, ignored you, or is waiting on something you have not noticed. That uncertainty is what makes software feel unusable, long before anything actually fails.

Most confusion in gOS is orientation rather than failure. Three things on screen answer nearly every question, and they are always in the same places.

Search desktop…gOSPapersDraft1read the sources, then wrote the outline2 files changed in this Space2write to references.bib?approve · reject31Where am Ithe breadcrumb names the Space2What changedthe last Sim message sayswhat it actually did3What is waitingan open approval blocks therun until you answer it
Where am I, what changed, what is waiting. Read those three in that order before changing anything.

01

Where am I, what changed, what is waiting.

The breadcrumb at the top left names the Space you are in, and the Space decides what a request can reach. The last message from the Sim says what it actually did. An open approval holds the run until you answer it. Reading those three, in that order, resolves most of it.

1Where am Ithe breadcrumb, top left2What changedthe last message from the Sim3What is waitingany approval still openIn that order. Most of what feels like a failure in gOS is one of these three not having been read yet,because the same sentence does different things in different Spaces.
In that order. The same sentence does different things in different Spaces.
  • The breadcrumb names the Space.
  • The last Sim message says what happened.
  • An open approval is blocking, not optional.

02

When a run stops, it names the reason.

Runs do not fail silently. A blocked run says which constraint stopped it: a path outside the Space, a tool that is not on the flow's allowlist, a call ceiling reached, an approval never answered. Several flows are written to pick up from exactly that point rather than starting the whole job again.

the run stopped, and said which constraint stopped ita path outside the Space→ widen the scope, or move the file ina tool not on the allowlist→ add it to the manifest, deliberatelythe call ceiling reached→ raise it, or split the job in twoan approval never answered→ answer itSeveral flows are written to resume from exactly the point that stopped them, choosing a smaller setof inputs, or revealing the folder they were reaching for, rather than starting the whole job again.A constraint is a sentence you can act on. That is the difference between a stop and a failure.
A constraint is a sentence you can act on. That is the difference between a stop and a failure.
  • Read the constraint, not the stack.
  • Widen the Space or the allowlist deliberately.
  • Recover from the stop, not from the start.

03

Diagnostics shows what the machine is doing.

Model residency, queue depth, memory pressure and recent errors sit on one surface. If gOS feels slow rather than wrong, that is the page to open first.

model residencywhat is loaded, and how much it is holdingqueue depthhow much work is waiting behind thismemory pressurewhether the machine is the bottleneckrecent errorswith reference codes, not stack tracesIf gOS feels slow rather than wrong, this is the page to open first, and usually the answer is on it.
If gOS feels slow rather than wrong, the answer is usually on this one page.
  • See which models are resident.
  • See how deep the queue is.
  • See what failed most recently.

04

Check Authorizations before blaming the Sim.

A flow that cannot see your calendar, your mail or your screen is usually a permission that was never granted rather than a broken agent. Settings → Authorizations lists every one of them, and revoking is the same click as granting.

Settings → Authorizationsevery capability gOS can be given, listed in one placeMailContactsCalendarRemindersMicrophoneScreen recordingGranting and revoking are the same click. A missing permission usually looks like a refusal,so check here before concluding the Sim would not do it.
Granting and revoking are the same click, and a missing permission looks exactly like a refusal.
  • Permissions are per capability.
  • Granting and revoking are the same click.
  • A missing permission looks like a refusal.

05

Ask from inside the session.

Support works better when it starts where the problem happened, with the Space, the run and the trace attached, than from a blank form. Reach out from the session and the context travels with the question.

asking from inside the sessionthe Space you are inthe run that stopped, and its tracethe approval that is still openasking from a blank forma description of a descriptionof something that happenedon a machine nobody can seeThe context travels with the question, so the first reply can be an answer rather than a request formore detail, and you decide what is attached before it goes.
The context travels with the question, and you decide what is attached before it goes.
  • Ask where the issue happened.
  • Share the run, not a retelling of it.
  • Keep private material scoped.

Help should make the system feel smaller: the same three places, every time.