vitya
9a518fcb43
Add a session_break marker so a task author can mark a task's completion as a natural session boundary. After the task closes 🟢, before tasks_claim_next, an autonomous agent prints the verbatim SESSION BOUNDARY line and stops instead of chaining the next task. Absent -> behaviour unchanged. - STATUS.md format: optional **Session break:** field + new "### session_break marker" subsection (type bool|string, examples). - Task completion step 6: after close, before claim-next, check the closed task's session_break; print boundary line + stop if present. - Rules bullet "Honour session_break". - Wiki concept page concepts/using-tasks-session-break.md + index + log. MINOR bump: new optional capability, no existing behaviour changed. Closes [session-break-using-tasks]. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
53 lines
2.3 KiB
Markdown
53 lines
2.3 KiB
Markdown
---
|
|
title: using-tasks session_break marker
|
|
type: concept
|
|
tags: [using-tasks, autonomous-runner, session-boundary]
|
|
updated: 2026-06-09
|
|
---
|
|
|
|
# using-tasks `session_break` marker
|
|
|
|
`using-tasks` v1.2.0 adds a `session_break` marker so a task author can mark a task's
|
|
completion as a natural place to **stop**, rather than have an autonomous agent immediately
|
|
chain into the next task via `tasks_claim_next`.
|
|
|
|
## Problem
|
|
|
|
An autonomous runner closes a task and, by default, claims the next one. There is no signal
|
|
for "this is a good seam to end the session" — so unrelated tracks get welded into one
|
|
ever-growing context, and the natural review/hand-off moment is skipped.
|
|
|
|
## Design
|
|
|
|
- **Marker:** `session_break` in the task's frontmatter (task-system delivery) or the
|
|
`**Session break:**` field in the task's STATUS.md block (local board mirror).
|
|
- **Type:** boolean or string.
|
|
- `true` → pause after close; next track is "see STATUS.md".
|
|
- `"<hint>"` → pause after close; the hint names the recommended next track.
|
|
- **Enforcement point:** `using-tasks` → Task completion, **step 6** — *after* the task is
|
|
🟢 and committed, *before* any `tasks_claim_next` / starting the next task.
|
|
- **Behaviour when present:** print the SESSION BOUNDARY line verbatim, then stop (do not
|
|
claim the next task).
|
|
- **Behaviour when absent:** unchanged — claim / start the next task as usual.
|
|
|
|
### Verbatim message
|
|
|
|
```
|
|
🔚 SESSION BOUNDARY — [slug] закрыта. Рекомендую завершить текущую сессию. Следующий трек: [value | "см. STATUS.md"]
|
|
```
|
|
|
|
`[slug]` = the closed task's slug. `[value | "см. STATUS.md"]` = the marker's string value,
|
|
or the literal `см. STATUS.md` when the marker is just `true`. The wording is fixed so the
|
|
boundary is greppable and recognisable across sessions.
|
|
|
|
## Why a marker, not a heuristic
|
|
|
|
The decision of *what counts as a stopping point* belongs to whoever scoped the work (the
|
|
delegating workshop), not to the runner mid-flight. A heuristic ("stop after N tasks", "stop
|
|
when tired") would either over- or under-fire. An explicit, opt-in marker keeps the default
|
|
unchanged and makes the boundary a deliberate authoring choice.
|
|
|
|
## Versioning
|
|
|
|
MINOR bump (1.1.0 → 1.2.0): new optional capability, no existing behaviour changed.
|