The session started with four parity gaps and ended with fifteen GitHub issues mapped against the full ecosystem. That’s a wider arc than planned.

The gap closure was straightforward. PRs F through J: BlackboardPlanConfigurer (the pre-registration mechanism treblereel had; we didn’t), strict PlanItem lifecycle (markRunning/markCompleted throwing on invalid transitions — the strict API immediately caught test code jumping PENDING→COMPLETED without going through RUNNING), SubCase data model, Stage.builder() requiring an explicit entry condition, and the binding gating pattern from the Kogito flexible process model. That last one became ADR-0002. The decision — presence of stage.addBinding() IS the opt-in, no flag needed — was the right one, and it held up well under questioning about whether all four approaches could equally work. They can’t. Approach C is the only one that’s both bounded and fair; A is unbounded; B punishes late claimants; D is a pragmatic middle ground.

The SLA continuation question got its own issue (#122) because it deserved its own lifecycle, not a comment on a design document. I put it in the wrong place the first time.

The ecosystem mapping came from a single question about the TaskBroker and WorkItems integration. That thread kept pulling: how the two systems compose, where the deadline enforcement boundary sits (TimeoutEnforcer fires; WorkItems owns the escalation policy), the claim model atomics, the HumanEscalationPolicy interface. Fifteen issues total — one for each use case where casehub + Qhorus

PropagationContext and the architectural exclusion tests went cleanly. The fitness tests asserting that NotificationService and CaseFileContribution are never ported — two test methods, five forbidden class names — are the right level of investment for confirming a decision.