This repository was archived by the owner on May 29, 2026. It is now read-only.
feat(openspec): actionitem-analytics-declarative-migration — second ADR-031 spec#147
Merged
rubenvdlinde merged 1 commit intoMay 7, 2026
Conversation
…DR-031-aware spec Specifies the migration of `ActionItemAnalyticsService::getCompletionRates()` into `x-openregister-aggregations` + `x-openregister-calculations` on the Meeting schema. The other two methods on the service stay as-is per ADR-031: - `getSummary()` — already declarative-first (thin AggregationRunner dispatch over named aggregations on ActionItem; commit e8b1812). - `getMyItems()` — legitimately imperative (user-specific filter + presentation bucketing; ADR-031 exception 2). So the "audit said this is the next service to migrate" reading collapsed under closer inspection — the service is mostly already right; one method needs migrating, two stay. Engine-dependency: shares the cross-schema aggregation (`@self.{relation}`) question with PR #146 (quorum-declarative-migration). Task 1 here is a lighter spike than #146's, verifying the back-relation direction (Meeting counting ActionItems where `meeting == @self.id`) once the forward direction (Meeting → Participants) is confirmed. Three artifacts: - proposal.md (90 lines) — what / why / capabilities. Honest about the audit's overstatement. - design.md (143 lines) — declarative-vs-imperative decision table for all three methods, engine-dependency call-out cross-referencing PR #146, controller wire-shape preservation note. - tasks.md (172 lines) — schema-register patches first, controller rewrite, service-method deletion, retain-imperative verification step for getSummary + getMyItems, materialise-refresh soft-gate test.
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:51 UTC
Download the full PDF report from the workflow artifacts.
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.
Second ADR-031-aware spec on decidesk, sister to PR #146 (quorum-declarative-migration).
Spec, not implementation. Sanity-check first; the goal is to verify the ADR-031 + opsx-ff template applies consistently across migrations.
Honest reframing
The 2026-05-06 readiness audit listed
ActionItemAnalyticsService → x-openregister-aggregationsas one of five high-leverage decidesk migrations. Re-reading the source against ADR-031, the picture is more nuanced:getSummary($from, $to)AggregationRunnerdispatch over named aggregations on ActionItem (commit e8b1812).getCompletionRates($limit)getMyItems($user)So one method to migrate, not three. Two are already right.
What this spec exercises
getSummary(already migrated) andgetMyItems(imperative) so future readers don't re-target them.@self.{relation}cross-schema aggregation question, opposite relation direction. Task 1 here is the lighter spike; if feat(openspec): quorum-declarative-migration — first ADR-031-aware spec #146 passed, this inherits the signal.Artifacts (431 LOC total)
proposal.md— what / why / capabilities. Honest about the audit's overstatement.design.md— Declarative-vs-imperative decision table for all three methods. Engine-dependency call-out. Controller wire-shape preservation note. Materialise-refresh risk surfaced.tasks.md— schema-register patches first, controller rewrite, service-method deletion, retain-imperative verification step, materialise-refresh soft-gate test, frontend Playwright smoke step.Sanity-check checklist
Notes
Markdown only. Worktree-built. Draft because it's a spec for sanity-check. Same admin-merge pattern as other Stage A/B work when you're ready.