Skip to content
This repository was archived by the owner on May 29, 2026. It is now read-only.

docs(openspec): populate example-change + 7 EXAMPLE capability specs#22

Closed
rubenvdlinde wants to merge 1 commit into
fix/adr-examplesfrom
docs/populate-example-specs-and-change
Closed

docs(openspec): populate example-change + 7 EXAMPLE capability specs#22
rubenvdlinde wants to merge 1 commit into
fix/adr-examplesfrom
docs/populate-example-specs-and-change

Conversation

@rubenvdlinde

Copy link
Copy Markdown
Contributor

Summary

Fills in the previously-missing openspec/changes/example-change/ directory that the template's @spec docblock tags point at, plus the 7 openspec/specs/ capabilities those tasks implement. All files carry example: true frontmatter and a prominent "⚠️ EXAMPLE SPEC" banner so derived apps can spot the demonstration content instantly.

Why

The template's lib/**/*.php already demonstrates the @spec annotation convention with 9 tasks referenced across 10 files — but openspec/changes/example-change/ didn't exist, so every tag resolved to a dead link. Running the openspec-* skills against a fresh clone hit immediate inconsistency. This PR makes the template internally consistent without changing any code.

Produced as the second half of a test pass on Wilco's opsx-reverse-spec skill — the first half was #176 (mydash legacy-widget-bridge run). Both runs surfaced learnings that will land in a sibling PR to feature/skill-improvement after this one settles.

Capabilities added (openspec/specs/)

Capability Source files Implements
dashboard-page DashboardController.php task-1
settings-management SettingsController.php + SettingsService.php task-2, task-3
deep-linking DeepLinkRegistrationListener.php task-4
item-management ItemController.php + ItemService.php task-5 (item part)
configuration-initialization Repair/InitializeSettings.php task-5 (repair part)
admin-ui Settings/AdminSettings.php + Sections/SettingsSection.php task-6, task-7
observability MetricsController.php + HealthController.php task-8, task-9

Each spec has 1–4 REQs with GIVEN/WHEN/THEN scenarios and explicit ADR references (003, 004, 005, 006, 011). Voice matches mydash / openregister conventions ("The system MUST...").

Change scaffold (openspec/changes/example-change/)

  • proposal.md — why this change exists, lifecycle guidance for apps cloning the template
  • tasks.md — 9 tasks matching the @spec task-N tags in lib/
  • design.md — design rationale including the known task-5 scope overlap (Item-auth + repair step share a task number; noted, not silently fixed)

What this PR does NOT do

  • No lib/**/*.php files are touched. All existing @spec openspec/changes/example-change/tasks.md#task-N annotations are left as-is; they now resolve correctly.
  • Does not archive the change. Archiving would move the delta into openspec/specs/ and remove the tasks, but the task file is what the code's @spec tags point at. Keeping the change in-progress (spiritually example) is what keeps the template internally consistent.
  • Does not add ADRs. The specs reference ADRs by number; those ADRs live in openspec/architecture/ and are out of scope here.
  • Does not add a specs/ delta inside the change directory. End-state specs live directly in openspec/specs/; duplicating as a delta would add maintenance cost without improving the demonstration.

Review focus

  • Does the example: true + banner markup communicate "don't copy this as your real spec"? If not, I'm open to stronger markers (a filename suffix, a dedicated CI rule, etc).
  • Is the task-5 scope overlap the right thing to document-but-not-fix? I considered splitting into task-5a / task-5b and editing three docblocks, but that felt like scope creep for a documentation PR.
  • Voice consistency with other OpenSpec capabilities (mydash has 9 capabilities using the same format — I followed it).

Test plan

  • @WilcoLouwerse review the example markers — strong enough?
  • Optional: run any openspec-* skill against this branch to confirm tasks/specs resolve cleanly.
  • Optional: grep lib/ for @spec example-change — all 15 references should match a task in tasks.md.

Related

  • #176 — opsx-reverse-spec learnings from the mydash run (sibling to this)
  • #177 — opsx-coverage-scan learnings (same)
  • A combined learnings PR with findings from both mydash + this template run will follow; app-versions is next up for a third data point.

Fills in the previously-missing openspec/changes/example-change/
directory that the template's @SPEC docblock tags point at, plus
the openspec/specs/ capabilities those tasks implement.

All files carry example: true frontmatter and an "EXAMPLE" banner
so derived apps can spot the demonstration content instantly.

Capabilities added (openspec/specs/):
- dashboard-page          (DashboardController — SPA entry + catch-all)
- settings-management     (SettingsController + SettingsService)
- deep-linking            (DeepLinkRegistrationListener)
- item-management         (ItemController + ItemService — ADR-005 demo)
- configuration-initialization (Repair/InitializeSettings — repair step)
- admin-ui                (AdminSettings + SettingsSection)
- observability           (MetricsController + HealthController — ADR-006)

Change scaffold (openspec/changes/example-change/):
- proposal.md  why the example-change exists; lifecycle guidance
- tasks.md     9 tasks matching the @SPEC task-N tags in lib/
- design.md    design rationale incl. known task-5 scope overlap

No lib/*.php files are touched. The existing @SPEC
openspec/changes/example-change/tasks.md#task-N annotations now
resolve correctly against this content.
@rubenvdlinde

Copy link
Copy Markdown
Contributor Author

Superseded by #61. The example-change + 7 capability specs this PR adds are reapplied on current development in #61, adapted to the post-manifest-refactor layout: task-5 / item-management / design.md no longer reference the deleted ItemController/ItemService; the per-object-auth illustration now points at ActionAuthService (ADR-023, merged in #21). The deliberate documentation-only (no delta dir) design you chose is preserved, and the actual CI gate (npm run check:specs) passes. No work lost.

@rubenvdlinde rubenvdlinde deleted the docs/populate-example-specs-and-change branch May 25, 2026 15:56
rubenvdlinde added a commit that referenced this pull request May 25, 2026
… populate example openspec (#61)

Consolidates the unique, still-unmerged work from the stale PRs #19, #20 and
#22 (their branches predated the manifest-renderer refactor and could not be
merged without reverting it), reapplied freshly on current development:

Headers / SPDX / @SPEC (was #19):
- Fix the propagated `dev@conductio.nl` -> `info@conduction.nl` typo across all
  10 template PHP files (root-cause fix; the typo had spread fleet-wide via
  scaffolds).
- Bump @copyright 2024 -> 2026 and add SPDX-FileCopyrightText /
  SPDX-License-Identifier inside the main docblock (after @license), matching
  the canonical format already used by lib/Mcp/ExampleToolProvider.php.
- Add the file-level @SPEC example to Application.php (ADR-003) so scaffolds
  show builders the convention.

Observability + REUSE (was #20):
- Add HealthController + MetricsController. appinfo/routes.php already declared
  metrics#index and health#index, but the classes were missing, so /api/health
  and /api/metrics returned 500. HealthController is public (@publicpage) and
  verifies OpenRegister; MetricsController is admin-only Prometheus text with
  {app}_info and {app}_health_status gauges (ADR-006).
- Add REUSE.toml for non-PHP source files.

Example OpenSpec (was #22):
- Populate openspec/changes/example-change/ + 7 openspec/specs/ capabilities
  that the @SPEC docblock tags point at, so the tags no longer resolve to dead
  links. Adapted task-5 / item-management / design.md to the current layout:
  the removed ItemController/ItemService demo is replaced by ActionAuthService
  (ADR-023, merged in #21) as the per-object-auth illustration.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants