Skip to content

Record a decision so the next worker can find it

Write down what was decided and why as state, then find it again without reading a conversation.

described Sessions and handoverbasicagentcontributorwrites state

Situation

A session decides something in the middle of a task: a trade-off, a refusal, a convention. The decision lives in the conversation, so the next worker either re-derives it, contradicts it, or reads the whole transcript to find it.

Scenario

setup: active-task
given:
  - 'an active task scoped to lib'
steps:
  - id: decide
    run: ['decision', 'add', 'refuse tabs in the parser', '--why', 'two encodings for one token']
    note: 'what was decided, why, and which task decided it; superseded by a later entry, never edited'
    expect:
      exit: 0
      stdout_contains: ['recorded: refuse tabs in the parser']
  - id: read-back
    run: ['decision', 'list']
    note: 'the decisions of this branch, newest first'
    expect:
      exit: 0
      stdout_contains: ['refuse tabs in the parser', 'Why: two encodings']
  - id: find-it
    run: ['search', 'tabs']
    note: 'a literal scan over the durable records, no index'
    expect:
      exit: 0
      stdout_contains: ['decision', 'match']
  - id: what-happened
    run: ['history']
    note: 'the ledger names the event and the task'
    expect:
      exit: 0
      stdout_contains: ['decision.recorded', 'task.started']
then:
  - 'a decision is one line of state with an author, a task and a reason'
  - 'nothing has to be re-explained to the next session'

Outcome

The decision is a record naming the task that made it and why; decision list reads it back, search finds it by a word, and the ledger says when it happened. A later decision supersedes it by naming it; nothing is edited.

No scenario yet

This use case is described, not proved: it names its commands and rules, and nothing executes it. It cannot be more than described until a scenario is added.

Why the tool knows this

The chain from this page to the code: the use case names commands, rules and claims; each rule is dispatched from the registry and each claim names the test that proves it; the scenario above executed the commands. Nothing in this chain is prose about intent.

The rules that make it hold

Guarantees exercised

Related use cases

Computed from what they share: claims, rules, commands, category, applications. Nobody maintains this list.

The moments this answers