Runs and live events

A run is one piece of work that WeHarness carries out for a workspace, optionally linked to a project. Each run has a state and an ordered list of events. You can follow the events live, and you can read them again later.

Examples of runs:

Run	What it does
A message	WeHarness’s reply to a session message, with the steps it took
Architecture plan	Builds one plan version for a project. See Plans and approval.
Decision	One Elephant-1 decision between options
Context index	Builds the search index for a newly committed snapshot. See Code search and the index.
Clean check, environment build	Runs the approved setup and checks in a fresh sandbox. See Cloud work.
Evaluation run	Runs a test set’s cases. See Evaluations.
Improve this agent	A bounded optimization run. See Improve this agent.
Export, purge	Prepares a workspace export, or deletes a disconnected source or a deleted project’s data
Connection check	Goes through the full path, from admission to the workflow engine to the live stream, without changing anything. A coding tool starts one with run_start.

States

State	Meaning
Queued	The run is admitted and waiting for a worker.
Running	A worker is executing the run’s steps.
Completed	All steps finished.
Failed	The run stopped because of an error.
Cancelling / Cancelled	The run is being stopped, or has stopped, at a person’s request: Stop on a reply, Cancel planning on a plan. A plan run also ends as Cancelled when a newer plan version replaced it.
Planning / Deciding	A plan run is drafting with the planner model, or waiting for an Elephant-1 decision.
Paused: dependency	The decision model is unavailable. The run retries on its own and continues where it stopped.
Awaiting approval / Needs input	A plan run handed the plan to a person: approve it, or answer its questions.

“Completed” means the steps finished. It is not a claim that any code is correct. Verification will have its own evidence, separate from the run’s state.

Events

Every event has a sequence number that starts at 1 and increases by one, with no gaps. A connection check produces these events:

#	Event	Meaning
1	run.received	The run was admitted.
2	run.started	The workflow started.
3–5	step.completed	Steps 1, 2 and 3 of 3 completed.
6	run.completed	The run completed.

Live stream and reconnects

The app shows events as they happen, over a standard Server-Sent Events stream. The stream sends a keep-alive signal every 15 seconds, so idle connections stay open.

If the connection drops, the browser reconnects and sends the number of the last event it received. WeHarness then sends only the missed events, each exactly once. When the run reaches a final state, the stream sends an end event and closes.

Reliability

Runs are recorded together with their start request, in one database transaction. A run cannot be lost between “accepted” and “started”, and it is started only once even if delivery is retried.

If the worker stops mid-run, the run continues from the last completed step when a worker is available again. Each step’s effect is recorded once, so a restart does not repeat work.