coulomb/coordination-engine
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add kind: decision commitments and depends_on entry for cross-owner waits (CUST-WP-0074-T03)
All checks were successful
check / test (push) Successful in 1m42s
Details
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: claude-fable-5-1
Assistant-Process: 237582@bnt-lap001
Assistant-Session: f2b3d9f1-8fb9-4b9c-bc2b-837ec5dfc826
This commit is contained in:
tegwick 2026-09-28 22:14:39 +02:00
parent 2c3cedaa37
commit 354e800d3b
2 changed files with 27 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

13
spec/coordination-model-v0.2.md
View file

@ -65,6 +65,7 @@ prj- workplan → CoordinationCase
driver ← the prj- workplan (commitment: sequence the effort)
implementers ← child workplans in other repos (related / depends_on)
commitments ← depends_on edges (kind: response | completion)
needs_human: true tasks (kind: decision)
observations ← State Hub task/workplan status, receipts
```
@ -72,7 +73,17 @@ prj- workplan → CoordinationCase
implementer (or upstream driver) named by the target id. The beneficiary
is the waiting plan. Satisfaction is the target reaching a terminal
satisfactory status (`done` / `finished` / `archived`), matching the
v0.1 worker-coordination dependency rule.
v0.1 worker-coordination dependency rule. Task-block `depends_on`
(fleet standard `task-wait-qualifiers_v0.1.md`, CUST-WP-0074) is the
same commitment with a task rather than a workplan as beneficiary; task
targets are satisfied at `done` / `cancel`.
**`kind: decision`** — a task with `needs_human: true` is a commitment
whose obligor is a person (or the decision named by `decision_id`), not
a workplan. Satisfaction is the person's recorded action or the
decision resolving. The engine observes it and never wakes a worker for
it. A task carrying both `depends_on` and `needs_human: true` is two
commitments; the case is satisfied only when both are.
`related:` without `depends_on` is context, not a commitment.

18
spec/cross-owner-wait-mode-v0.1.md
View file

@ -18,10 +18,20 @@ theme holding the open-workplan count up.
Any of:
1. A task is `wait` / `needs_human` and names another repo, owner, or
workplan id.
1. A task is `wait` with a task-block `depends_on` naming a workplan or
task in another repo (fleet standard
`the-custodian/canon/standards/task-wait-qualifiers_v0.1.md`). Prose
that names another repo, owner or workplan id without `depends_on`
remains an entry condition only until the CUST-WP-0074-T05 backfill
completes; it is an unqualified wait and should be converted.
2. A workplan is `blocked` on a `depends_on` target whose `repo` is not
this repo.
A task with `needs_human: true` is a **human gate**, not a cross-owner
wait. It does not enter this mode; it is a `kind: decision` commitment
(coordination-model v0.2 §5) satisfied only by the named person or the
resolution of its `decision_id`. A task carrying both `depends_on` and
`needs_human: true` enters this mode for the `depends_on` part only.
3. A `prj-` driver lists both repos (preferred). If no driver exists,
still open a **case object** from the waiting plan — do not author a
new workplan.
@ -47,7 +57,9 @@ commitment.
Lease/wakeup **only** selected gita-registered worker targets for the
implementer that is actually unblocked. Safety, sensitive-text stops,
human flags, and “no silent reroute” are exactly the v0.1 worker service.
This mode does not add a second wakeup path.
This mode does not add a second wakeup path. A human-gate task
(`needs_human: true`) is never leased or woken: it is a stop condition,
and a worker that reaches one checkpoints with `blocked_reason` and exits.
If the service is not running, the case still exists as a derived object
and a hub-projectable receipt of `observed` / `waiting`. Agents follow