Context
During Epic 2 (domain model) design, three concepts were in the original capability vocabulary:
- `BATCH_BISECT`
- `COORDINATED_MERGE`
- `COORDINATED_ROLLBACK`
These are orchestration operations — structural moves a case plan makes — not capabilities an agent is trust-scored for. They should be expressed as CasePlanModel binding conditions and sub-case structures (Epics 4, 5), not as capability tags fed to `LedgerAttestation` or `TrustGateService`.
Naming challenge
Current names are Gastown/git-vocabulary. Better names should reflect what the case is actually doing from an ACM perspective:
| Current name |
Git/ops meaning |
ACM framing |
Candidate names |
| `BATCH_BISECT` |
Binary search for faulty commit |
Fault isolation — narrow an unknown batch failure to one PR |
`BatchFaultIsolation`, `MergeQueueFaultNarrow`, `PRFaultIsolation` |
| `COORDINATED_MERGE` |
Atomic merge across repos |
Federated atomic completion — all sub-cases complete, trigger coordinated merge |
`FederatedMerge`, `AtomicCrossRepoMerge`, `CoordinatedCompletion` |
| `COORDINATED_ROLLBACK` |
Undo across repos on failure |
Federated compensation — sub-case fault triggers compensating actions |
`FederatedCompensation`, `FaultCompensation`, `CrossRepoCompensation` |
`FederatedCompensation` uses saga pattern terminology and is more general than "rollback" — a compensating action need not always be an undo.
Decision rule
Finalise names when Epics 4 and 5 are designed — the name that reads most naturally in the YAML case definition is the right name. Defer until then.
Action
Do not add these to `devtown-domain` vocabulary (Epic 2). When Epic 4 (merge queue) and Epic 5 (cross-repo) are designed, model them as CasePlanModel binding structures.
Refs #9 (Epic 2), #11 (Epic 4), #12 (Epic 5)
Context
During Epic 2 (domain model) design, three concepts were in the original capability vocabulary:
These are orchestration operations — structural moves a case plan makes — not capabilities an agent is trust-scored for. They should be expressed as CasePlanModel binding conditions and sub-case structures (Epics 4, 5), not as capability tags fed to `LedgerAttestation` or `TrustGateService`.
Naming challenge
Current names are Gastown/git-vocabulary. Better names should reflect what the case is actually doing from an ACM perspective:
`FederatedCompensation` uses saga pattern terminology and is more general than "rollback" — a compensating action need not always be an undo.
Decision rule
Finalise names when Epics 4 and 5 are designed — the name that reads most naturally in the YAML case definition is the right name. Defer until then.
Action
Do not add these to `devtown-domain` vocabulary (Epic 2). When Epic 4 (merge queue) and Epic 5 (cross-repo) are designed, model them as CasePlanModel binding structures.
Refs #9 (Epic 2), #11 (Epic 4), #12 (Epic 5)