Skip to content

Say what reached the remote and what did not

The obligations that reach past the working tree are settled by asking git and the published site, so a report cannot call uncommitted work committed or unpushed work pushed.

guaranteed Completion and quality gatesbasicmaintaineragentwrites state

Situation

Implemented, committed, pushed, integrated, published and deployed are six different facts, and a report that treats them as one is not a report. A worker can finish a change, run its tests, satisfy every line of the finish contract, and leave the work sitting in the working tree of one laptop.

The obligation vocabulary already had tokens for all six. What it did not have was anybody asking: each was discharged by a person running something and typing that they had. Git holds four of those answers and has held them all along.

Scenario

setup: task-owes-outer
given:
  - a repository with the layer installed, an active task that owes commit and push, and the work still in the working tree
steps:
  - id: recording-it-changes-nothing
    run: ['evidence', '--covers', 'commit', '--command', 'git commit']
    expect:
      exit: 0
      output: 'evidence: commit recorded'
  - id: the-tree-is-asked-instead
    run: ['finish', '--outcome', 'completed', '--note', 'done']
    expect:
      exit: 10
      output: 'still in the working tree'
  - id: what-cannot-be-settled-says-so
    run: ['check']
    expect:
      exit: 0
      output: 'the checkout has no remote'
then:
  - a token the tool can settle is settled live at HEAD, and a recorded line neither discharges it nor rescues it
  - a checkout that cannot settle a token falls back to the recorded evidence and says what it could not establish
  - unreachable and unpublished are different findings, and neither is reported as the other

Outcome

The words in the report are the words for what happened. Work in the tree is not committed, a commit the remote has not seen is not pushed, a branch the trunk does not reach is not integrated, and a site that never answered is not a site serving an old commit. None of those distinctions costs a worker anything to maintain, because none of them is maintained by a worker.

The scenario

Executed against the real tool, in a repository prepared by task-owes-outer, every time this site is generated. What follows is not a description of what should happen; it is what happened.

given

  • a repository with the layer installed, an active task that owes commit and push, and the work still in the working tree

when

  1. 1majordomus evidence --covers commit --command git commit
  2. 2majordomus finish --outcome completed --note done
  3. 3majordomus check

then

  • a token the tool can settle is settled live at HEAD, and a recorded line neither discharges it nor rescues it
  • a checkout that cannot settle a token falls back to the recorded evidence and says what it could not establish
  • unreachable and unpublished are different findings, and neither is reported as the other

What the tool did

Evidence of the run this page was generated from: pass, 3 step(s). Output is normalised: the repository's path, timestamps, ids and durations are placeholders; nothing else is edited.

Tested by test/cases/94_use_cases.sh, which runs every scenario and refuses a step whose recorded output is not what it produced.

  1. evidence: commit recorded for t-<id>
              note: commit is established from git where it can be, and this record is read only where it cannot
    • exit 0
  2. OK   blockers    t-<id> — none open
    FAIL note        t-<id> — no --note file and no handover for this task  [reproduce: majordomus handover < note.md]
    INFO regression  t-<id> — profile implementation adds no requirement beyond the shared contract
    OK   scope       t-<id> — 1 touched file(s), all within scope
    OK   state       t-<id> — exact (head <head>)
    INFO continuity  t-<id> — applies to partial and blocked
    INFO mesh        t-<id> — the repository declares no enabled mesh
    INFO use-case    30 advisory gap(s) — not covered by an active use case, and the policy does not require it: command:init command:update command:doctor command:watch command:start command:context command:checkpoint command:handover command:check command:finish command:history command:decision command:question command:prompt command:evidence command:skills command:capture command:search command:doctrine command:plan command:version command:session command:knowledge command:adr command:usecase command:rules command:migrate command:recover command:bench command:archive  [reproduce: majordomus usecase coverage]
    OK   use-case    0 of 30 target(s) covered — every public command the policy requires is named and run by an active use case (policy use_cases.coverage)
    FAIL verification t-<id> — profile implementation requires --verify-command  [reproduce: majordomus finish --outcome completed --verify-command "<cmd>"]
    FAIL obligation  commit — 1 file(s) the task touched are still in the working tree, not in the branch's history (lib/a)  [reproduce: git status --porcelain]
    FAIL obligation  push — owed, and no evidence was recorded (the checkout has no remote, so a push cannot be established here)  [reproduce: majordomus evidence --covers push --command 'git']
    INFO gate        t-<id> — this repository declares no CI model at .ai/repo/ci/gates.yaml; nothing can be planned
    INFO gate        t-<id> — not in verification.finish_requires
    finish: refused, 4 unmet
    blocking doctrines:
    - majordomus.note-integrity
    - majordomus.verification-integrity
    - majordomus.obligation-closure
    • exit 10
  3. OK   knowledge   records — 0 record(s) valid against knowledge/v1; every reference resolves  [reproduce: majordomus knowledge check]
    ·    checkpoint  t-<id> — <timed against the checkpoint interval>
    OK   records     ledger.jsonl — every line is a well-formed event
    OK   blockers    t-<id> — none open
    OK   records     decisions.md — every entry is attributable
    OK   scope       t-<id> — 1 touched file(s), all within scope
    OK   state       t-<id> — exact (head <head>)
    INFO mesh        t-<id> — the repository declares no enabled mesh
    INFO use-case    30 advisory gap(s) — not covered by an active use case, and the policy does not require it: command:init command:update command:doctor command:watch command:start command:context command:checkpoint command:handover command:check command:finish command:history command:decision command:question command:prompt command:evidence command:skills command:capture command:search command:doctrine command:plan command:version command:session command:knowledge command:adr command:usecase command:rules command:migrate command:recover command:bench command:archive  [reproduce: majordomus usecase coverage]
    OK   use-case    0 of 30 target(s) covered — every public command the policy requires is named and run by an active use case (policy use_cases.coverage)
    INFO obligation  commit — 1 file(s) the task touched are still in the working tree, not in the branch's history (lib/a) (not refused: the outcome is not completed)
    INFO obligation  push — owed, and no evidence was recorded (the checkout has no remote, so a push cannot be established here) (not refused: the outcome is not completed)
    INFO gate        t-<id> — this repository declares no CI model at .ai/repo/ci/gates.yaml; nothing can be planned
    check: 13 finding(s), 0 failing
    • exit 0

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.

Searches the titles and descriptions of every page this site publishes.