This repository was archived by the owner on May 29, 2026. It is now read-only.
feat(openspec): quorum-declarative-migration — first ADR-031-aware spec#146
Merged
Merged
Conversation
Migrates Meeting's quorum logic from `lib/Service/QuorumService.php`
(168 LOC, 2 methods) into `x-openregister-aggregations` +
`x-openregister-calculations` on the Meeting schema, per the new
ADR-031 (schema-declarative business logic over service classes)
that landed in hydra/development on 2026-05-06.
QuorumService is consumed exclusively by `MeetingTransitionGuard`
during the `scheduled → opened` transition. The guard itself stays
in PHP — ADR-031 explicitly preserves lifecycle guards as a
legitimate PHP seam — but it gets dumber: reads `meeting.quorumMet`
from the object instead of calling QuorumService.
Three artifacts:
- proposal.md — what / why / capabilities / stakeholders.
- design.md — declarative-vs-imperative decision table per ADR-031,
engine-dependency call-out (the migration depends on
cross-schema aggregation filters via `@self.{relation}`; if the
OR engine doesn't yet support that, ADR-031 exception 1 applies
and we file an OR feature request instead of a workaround
service).
- tasks.md — schema-register patches first (no new Service class
authored), spike-then-rest gate on task 1.
This is intentionally the smallest of the five planned decidesk
service migrations and the canonical worked example for the rest
(VotingService → lifecycle, ActionItemAnalyticsService →
aggregations, DecisionNotificationService → notifications,
OverdueActionItemsJob → processing). Sanity-check first; if the
shape reads right, Hydra picks up the bigger four with the same
template.
Contributor
Quality Report — ConductionNL/decidesk @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ❌ | ||||
| stylelint | ❌ | ||||
| composer | ✅ | ✅ 100/100 | |||
| npm | ❌ | ❌ | |||
| PHPUnit | ⏭️ | ||||
| Newman | ⏭️ | ||||
| Playwright | ⏭️ |
Quality workflow — 2026-05-06 14:22 UTC
Download the full PDF report from the workflow artifacts.
5 tasks
This was referenced May 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
First ADR-031-aware OpenSpec change on decidesk. Specifies the migration of Meeting's quorum logic from
lib/Service/QuorumService.php(168 LOC, 2 methods) intox-openregister-aggregations+x-openregister-calculationson the Meeting schema inlib/Settings/decidesk_register.json.This is only the spec, not the implementation. Sanity-check first; once the shape reads right, the same template covers the four remaining service migrations (VotingService → lifecycle, ActionItemAnalyticsService → aggregations, DecisionNotificationService → notifications, OverdueActionItemsJob → processing).
Why this one is the canonical worked example
QuorumService is the smallest of the five planned migrations (168 LOC) and crucially exercises the full ADR-031 decision tree, not just the happy path:
@self.{relation}filters, which existing decidesk aggregations don't yet exercise.MeetingTransitionGuardstays in PHP per ADR-031 (lifecycle guards are explicitly preserved). It just gets dumber — reads a field instead of calling a service.Artifacts
proposal.md— problem / proposed solution / capabilities / stakeholders / references.design.md— Declarative-vs-imperative decision table per ADR-031 + opsx-ff's new artifact rule. Engine-dependency call-out. Reuse / dedup analysis. Risks. Out of scope.tasks.md— schema-register patches only; no new Service class authored. Task 1 is a spike that gates tasks 2-7 on engine capability. Three guard rails in the trailer (no escape-hatch service, don't migrate the guard, don't expand scope).Sanity-check checklist
design.md§ Declarative-vs-imperative decision: does the table match what ADR-031 asks for? (Each behaviour has a path + rationale; legitimate PHP cases are explicit.)tasks.md: do the register-patch JSON snippets look syntactically right against ActionItem's existing aggregations + calculations? (Sample expressions:if/mul/div/eq/or/gte. Adjust operator names if engine uses different keys — flagged in task 3.)schema:+@self.governanceBody) something the OR engine currently supports? If yes, the migration ships as written. If no, ADR-031 exception 1 + OR feature request.Notes
Markdown only, no code paths affected. Worktree-built per the standing rule (decidesk's main checkout has WIP on
feature/declarative-annotation-pilot). Draft because I want your eyes on the spec shape before we apply the same template to the other four migrations.