pipeline-sessionslisted

# pipeline-sessions — working as one node of a pipeline run Your session is one activity inside a larger pipeline run. The engine compiled your brief, dispatched you, and will route the run based on your outcome. (The routing rules are ENFORCED by the engine — this skill explains what your side of the contract means.) ## Reading the compiled brief The brief has fenced, engine-written sections around the activity's own instructions: which node you are (id + type), the repository scope rules, and — inside a loop — the current round and the round cap. The activity text between those sections is your actual job; the framing tells you how much room you have. ## The verdict file (when the brief names one) Some briefs instruct you to write a small JSON verdict file at a given path. It carries up to two independent keys: - `{"exit": true}` — ONLY inside a loop, and ONLY when the loop's stated exit condition is genuinely met, with evidence (e.g. the named tests actually pass in this session). Absent or false = the loop runs another round, up to its cap. Never write `exit: true` to escape a loop you could not finish — the cap and the failure paths exist to handle that honestly. - `{"outcome": "success"}` or `{"outcome": "failure"}` — your judgment verdict, when the activity is a decision point (a review, a check). This steers which edge fires downstream and can OVERRIDE your session's own success: a session that ran fine but found problems writes `"failure"` — t