From d9a5014c7cc4e00f81dc1aa5f80a33e624d12235 Mon Sep 17 00:00:00 2001
From: Ruben van der Linde <rubenvdlinde@gmail.com>
Date: Wed, 22 Apr 2026 14:04:40 +0200
Subject: [PATCH 1/3] chore(openspec): add-features-roadmap-menu change
 proposal

Proposes a cross-repo Features & Roadmap menu item mounted in every
Conduction app's NcAppNavigationSettings slot above the gear.

- Features tab: shipped capabilities from openspec/specs/, extracted
  at build time into docs/features.json (committed, also powers
  Docusaurus public features page)
- Roadmap tab: open GitHub issues from the app's own repo, sorted by
  reactions, with pipeline-label blocklist and full markdown body
  rendering
- Suggest-feature modal launched from the route header and from any
  widget/page declaring a specRef via its NcActions menu
- Extends existing GitHubHandler with listIssues() + createIssue();
  user PAT preferred, server PAT fallback with attribution prefix
- Out of scope: ADR-019 fleet rollout, Discussions, Accept->specter wiring

Capabilities:
- github-issue-proxy
- features-roadmap-menu

Validates strict.
---
 .../add-features-roadmap-menu/.openspec.yaml  |   2 +
 .../add-features-roadmap-menu/design.md       | 368 +++++++++++++++
 .../add-features-roadmap-menu/proposal.md     | 132 ++++++
 .../specs/features-roadmap-menu/spec.md       | 428 ++++++++++++++++++
 .../specs/github-issue-proxy/spec.md          | 327 +++++++++++++
 .../add-features-roadmap-menu/tasks.md        |  86 ++++
 6 files changed, 1343 insertions(+)
 create mode 100644 openspec/changes/add-features-roadmap-menu/.openspec.yaml
 create mode 100644 openspec/changes/add-features-roadmap-menu/design.md
 create mode 100644 openspec/changes/add-features-roadmap-menu/proposal.md
 create mode 100644 openspec/changes/add-features-roadmap-menu/specs/features-roadmap-menu/spec.md
 create mode 100644 openspec/changes/add-features-roadmap-menu/specs/github-issue-proxy/spec.md
 create mode 100644 openspec/changes/add-features-roadmap-menu/tasks.md

diff --git a/openspec/changes/add-features-roadmap-menu/.openspec.yaml b/openspec/changes/add-features-roadmap-menu/.openspec.yaml
new file mode 100644
index 0000000000..25345f4206
--- /dev/null
+++ b/openspec/changes/add-features-roadmap-menu/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-22
diff --git a/openspec/changes/add-features-roadmap-menu/design.md b/openspec/changes/add-features-roadmap-menu/design.md
new file mode 100644
index 0000000000..bff57a43d5
--- /dev/null
+++ b/openspec/changes/add-features-roadmap-menu/design.md
@@ -0,0 +1,368 @@
+# Design: Add Features & Roadmap Menu
+
+## Context
+
+Every Conduction Nextcloud app ships with two sources of truth that today are invisible to
+users:
+
+1. **OpenSpec specs** under `openspec/specs/*/spec.md` describe the capabilities that are
+   actually built. Each spec has YAML frontmatter (`status: implemented | reviewed | redirect`),
+   a single `# Title` H1 that matches the capability directory, and a `## Purpose` section with
+   a short business summary. Today this tree is only read by developers and by the OpenSpec CLI.
+2. **GitHub issues** in each app's repository capture the roadmap: bugs, enhancement requests,
+   epics. Reactions (`+1`) already act as an informal voting signal from users who discover the
+   issue tracker.
+
+The goal is to expose both of these inside the app itself — one menu entry, a dedicated route
+with two tabs — and to add a submission path that lets users file feature requests straight
+into the repo without leaving the product.
+
+**Scope pivot:** the first iteration of this design deferred user submissions as a follow-up.
+The user reopened that decision because the submission path IS the critical value proposition
+("the most important part"). Submission is therefore back in scope for this change; the
+design below reflects that reopening.
+
+OpenRegister is the framework dependency shared by every Conduction Nextcloud app, so that is
+where the backend (read proxy + submission endpoint) lives. `@conduction/nextcloud-vue` is
+the shared Vue component library (currently exporting only settings primitives), so that is
+where the UI component family lives. The build-time spec-to-manifest tool is introduced as a
+third package, `@conduction/openspec-manifest`, because it must be usable from any app's
+build without dragging in the full UI library. A fourth package,
+`@conduction/docusaurus-features`, renders the same manifest on each app's public
+Docusaurus site.
+
+## Goals
+
+- One menu entry → one dedicated route with two tabs, every Conduction app. Consistent
+  placement above the Settings gear in `NcAppNavigationSettings`.
+- Features surfaced from OpenSpec specs at build time (no runtime filesystem walk, no backend
+  read path for feature metadata). Same manifest powers the in-app view and the Docusaurus
+  public page.
+- Roadmap items fetched live from GitHub with a short cache, full markdown rendering (XSS-
+  sanitized), and a blocklist that hides pipeline/workflow labels.
+- Submission directly to GitHub Issues, preferring the user's own token for authorship and
+  falling back to the app-level token with an authorship prefix when the user has none.
+- Widgets and pages may declaratively opt into a `specRef` — reusing the ADR-008 capability-
+  slug convention — so the "Suggest feature" action appears contextually wherever the user
+  is working.
+- Reuse the existing `GitHubHandler` + both PAT stores; reuse the existing admin UI for PAT
+  configuration; no new secret storage.
+- Ship the pilot wiring on OpenRegister itself in this change.
+
+## Non-Goals
+
+- GitHub Discussions integration — user explicitly chose Issues.
+- "Accept feature → auto-generate spec" pipeline (future: specter integration).
+- Fleet-wide adoption across every Conduction app (future: ADR-019 in hydra).
+- Editing or moderating issues from inside the app (create + read only; no close, no comment).
+- Private / enterprise repos in this iteration. Public repos only.
+- Webpack plugin wrapper for the manifest generator (CLI only in this iteration).
+
+## Decisions
+
+### D1. Runtime storage: none (thin proxy)
+
+We do NOT persist GitHub issues into an OpenRegister register, nor do we persist a per-instance
+copy of features. Alternatives considered:
+
+- **Per-instance register of features and issues, synced nightly.** Rejected: creates drift,
+  requires a sync worker, duplicates data we already have at source, and was explicitly
+  rejected by the user.
+- **In-app static JSON only for features, no roadmap at all.** Rejected: roadmap is the main
+  engagement driver and is cheap if proxied with caching.
+- **Chosen:** thin cached proxy for roadmap, build-time JSON bundle for features, direct
+  proxy for submissions.
+
+Rationale: minimizes blast radius, zero new data model, survives backend outages for features
+(since they're bundled into JS), and single-source-of-truth for both.
+
+### D2. GitHub read auth: reuse `openregister::github_api_token` (IAppConfig)
+
+Alternatives:
+
+- Per-user PAT only. Rejected for read: the roadmap is public data; burdening every user with
+  configuring a PAT defeats the point of "works out of the box."
+- Anonymous read (no auth). Rejected: 60 req/hour per IP is not enough for a component that
+  polls on panel open; will rate-limit quickly across a fleet of apps.
+- **Chosen:** reuse the admin-configured app-level PAT for reads. Admin configures once; all
+  users benefit.
+
+### D3. Features source: build-time manifest from `openspec/specs/`
+
+- Runtime endpoint reading specs from the installed app's filesystem. Rejected: couples the
+  backend to the app's deployment layout.
+- Hand-authored JSON curated per release. Rejected: guaranteed to drift.
+- **Chosen:** `@conduction/openspec-manifest` CLI runs as a `prebuild` step, writes
+  `docs/features.json`, both webpack/vite and Docusaurus consume that same file.
+
+### D4. Feature filter: `status: implemented` OR `status: reviewed`
+
+- `implemented` only. Rejected: `reviewed` is strictly more finished, not less.
+- Include `redirect`. Rejected: redirects are capability re-homing markers, not features.
+- Include drafts / planned. Rejected: the Features tab must show what actually ships.
+- **Chosen:** `status ∈ {implemented, reviewed}`.
+
+### D5. Docs link default
+
+- Require every spec to add a `docsUrl:` frontmatter key. Rejected: high-friction migration.
+- No link at all. Rejected: users who want detail should be able to get it.
+- **Chosen:** auto-compute against the repo's default branch resolved from `origin/HEAD`,
+  never the currently checked-out branch. Specs can opt in to an override via a `docsUrl:`
+  frontmatter key.
+
+### D6. Manifest generator as a standalone npm package
+
+- Ship as a dev-dependency module inside `@conduction/nextcloud-vue`. Rejected: couples build
+  tooling to the UI library; every app consumes the UI lib but only some apps have OpenSpec.
+- Inline script per app, copy-pasted. Rejected: DRY violation across ten-plus apps.
+- **Chosen:** new `@conduction/openspec-manifest` package with a `build` CLI.
+
+### D7. Component home: `@conduction/nextcloud-vue`
+
+The `@conduction/nextcloud-vue` library currently exports `CnSettingsCard` and
+`CnSettingsSection`. The new `CnFeaturesAndRoadmapLink`, `FeaturesAndRoadmapView`,
+`SuggestFeatureModal`, and `useSpecRef` additions set the convention for a new component
+category: "cross-app surfaces."
+
+### D8. i18n
+
+The component ships with Dutch (nl) and English (en) strings for all chrome (route title,
+tab labels, modal fields, empty states, toasts, error hints). Feature titles and summaries
+pass through unchanged — specs are single-source.
+
+### D9. Cache TTL: 15 minutes in-memory, global (per-instance)
+
+- Per-user cache. Rejected: same data for everyone; no personalization.
+- Longer TTL (1 hour). Rejected: roadmap engagement benefits from fresh-feeling data.
+- Shorter TTL (1 min). Rejected: wastes rate-limit budget.
+- **Chosen:** 15 min in-memory cache, keyed by `(repo, state, sort, per_page)`, global per
+  instance.
+
+### D10. Graceful degradation when PAT is missing
+
+The read endpoint returns `200 { items: [], hint: "github_pat_not_configured" }` rather than
+`403` or `500`. Features tab is unaffected.
+
+### D11. Pilot scope: OpenRegister only
+
+- Ship adoption into every Conduction app in this single change. Rejected: huge blast
+  radius for a first-time shared component.
+- **Chosen:** wire only OpenRegister in this change. Fleet rollout is a separate hydra
+  ADR-019.
+
+### D12. UI pattern: full route, not side panel
+
+- Side panel (`NcAppSidebar`). Considered; would be less intrusive but provides a cramped
+  surface for browsing + submitting feature requests, and awkward on mobile.
+- Modal. Rejected: too restrictive for two-tab browsing.
+- **Chosen:** dedicated Vue route (e.g. `/features-roadmap`). The
+  `NcAppNavigationSettings` entry is an `<NcAppNavigationItem>` that navigates to this
+  route. Provides a richer surface for browsing Features, the Roadmap, and filing new
+  requests from one page.
+
+### D13. Submission destination: GitHub Issues (not Discussions)
+
+- Discussions. Rejected: harder to link to the roadmap tab, which reads Issues; user
+  explicitly preferred Issues.
+- **Chosen:** Issues. Direct roadmap visibility; the new submission shows up immediately in
+  the same Roadmap tab where it was filed.
+
+### D14. Authorship fallback: user-PAT preferred, server-PAT fallback with attribution
+
+- PAT-required (every submitter must configure their own PAT). Rejected: heavy UX friction
+  for a feature whose point is low-friction.
+- Server-PAT only. Rejected: every issue would appear to be filed by the bot account;
+  attribution lost.
+- **Chosen:** prefer `openregister::github_token` (IConfig per-user); fall back to
+  `openregister::github_api_token` (IAppConfig) when the user has no token; on fallback,
+  prefix the issue body with
+  `> Submitted by **<nc_user_display_name>** via <nc_instance_url>\n\n---\n\n` so
+  traceability survives.
+
+### D15. Markdown rendering: `marked` + `DOMPurify`
+
+- Plain-text body rendering (no markdown). Rejected: GitHub issue bodies are commonly
+  markdown; plain rendering looks broken (raw `*`, `#`, code fences).
+- Iframe-embed GitHub's render. Rejected: XSS-free but no style control, slow, and breaks
+  dark mode theming.
+- First-paragraph-only + "Read more on GitHub." Rejected by the user in favor of full
+  markdown.
+- **Chosen:** `marked` to parse GitHub-flavored markdown, `DOMPurify` with a strict
+  allowlist to sanitize (no `<script>`, no `on*` attributes, no `javascript:` URLs, no
+  `<iframe>`, no `<style>`). The strict DOMPurify config is exported from
+  `@conduction/nextcloud-vue` so any consumer of user-generated markdown can reuse it.
+
+### D16. Label filter strategy: explicit blocklist
+
+- Allowlist of known user-facing labels. Rejected: new labels invented over time (e.g.
+  `accessibility`, `security`) would silently disappear from the UI until someone added them
+  to the allowlist.
+- Show everything. Rejected: Hydra pipeline/workflow labels
+  (`build:...`, `code-review:...`, `ready-for-code-review`, etc.) are internal and noisy.
+- **Chosen:** explicit blocklist as a regex set:
+  - `^build:`
+  - `^code-review:`
+  - `^security-review:`
+  - `^applier:`
+  - `^retry:`
+  - `^rebuild:`
+  - `^fix:`
+  - `^fix-iteration:`
+  - `^build-retry:`
+  - `^ready-`
+  - `^needs-input$`
+  - `^yolo$`
+  - `^openspec$`
+  - `^agent-maxed-out$`
+  - `^pipeline-active$`
+  - `^done$`
+  - `:queued$`
+  - `:running$`
+  - `:pass$`
+  - `:fail$`
+
+Anything else passes through and renders with its native GitHub color.
+
+### D17. `features.json` location: committed to git at `docs/features.json`
+
+- `src/features.json` + gitignored (original design). Rejected because the same file must
+  power the public Docusaurus page; we cannot ship a public page from a gitignored artifact
+  (Docusaurus would see a missing file in CI).
+- Two files (one for bundle, one for Docusaurus). Rejected: guaranteed to drift.
+- **Chosen:** single committed `docs/features.json`. The CLI is still idempotent and
+  deterministic; re-running `prebuild` before any build regenerates it so a stale manifest is
+  caught in the diff.
+
+### D18. Widget/page `specRef` contract: declarative, ADR-008-aligned
+
+- Imperative `registerSpecRef('slug')` call in each widget/page's `mounted()`. Rejected:
+  harder to audit at rest, not colocated with the component definition, easy to forget.
+- **Chosen:** declarative. Widgets use `defineOptions({ specRef: 'slug' })` (Composition API)
+  or a component option `specRef: 'slug'` (Options API). Pages use Vue Router
+  `meta: { specRef: 'slug' }`. The slug is a kebab-case capability slug — identical
+  convention to ADR-008 `@spec` PHPDoc annotations on the backend. `useSpecRef()` reads
+  either source.
+
+### D19. Docusaurus integration: shared `@conduction/docusaurus-features` package
+
+- Per-app Docusaurus code. Rejected: DRY violation across ten-plus apps.
+- In-app component rendered into Docusaurus. Rejected: Vue-in-Docusaurus integration is not
+  worth the tooling overhead; Docusaurus is React.
+- **Chosen:** new shared package `@conduction/docusaurus-features` exports a React
+  `<FeaturesPage />` component that loads `docs/features.json` and renders alphabetically,
+  matching the in-app visual style as closely as Docusaurus theming allows.
+
+### D20. Endpoint CSRF posture
+
+- Both GET and POST carry `#[NoCSRFRequired]`. Rejected: POST mutates external state (creates
+  a GitHub issue on behalf of the user). Must carry CSRF protection.
+- Neither carries `#[NoCSRFRequired]`. Rejected: GET is pure read with no mutation; requiring
+  CSRF tokens on every roadmap fetch adds unnecessary friction.
+- **Chosen:** `#[NoCSRFRequired]` on `GET /api/github/issues`, no such attribute on
+  `POST /api/github/issues` (CSRF MUST apply).
+
+### D21. Submission rate limit: APCu-backed, 1 per user per 60s
+
+- Database-backed rate limiter. Rejected: heavy, and the rate limit is ephemeral by design.
+- No rate limit. Rejected: abuse/spam path on a server-PAT fallback is obvious.
+- **Chosen:** APCu key `openregister.feature_submission:<user_id>` with 60s TTL; return 429
+  with `{error: "rate_limited", retry_after: <seconds>}` when exceeded.
+
+### D22. Spec-dir discovery: prefer `openspec/specs/`, fall back to `./specs/`
+
+- Only `openspec/specs/`. Rejected: legacy apps pre-dating the `openspec/` convention.
+- Only `./specs/`. Rejected: breaks the current canonical layout.
+- **Chosen:** prefer `openspec/specs/`, fall back to `./specs/`, emit a warning when both
+  are present so the ambiguity is visible.
+
+## Risks / Trade-offs
+
+- **GitHub read rate-limit exhaustion.** With an app-level PAT the unauthenticated 60/hr
+  limit becomes 5000/hr; the 15-min cache further reduces it to a handful of real calls per
+  day per instance. Mitigation: cache TTL tunable via app config; endpoint surfaces 429 with
+  `reset_at`.
+- **Server-PAT exhausted by spam submissions.** A bad actor could use a user without a
+  personal PAT to spam the server-PAT with issues. Mitigation: per-user APCu rate limit
+  (1/60s); admin can revoke/rotate the server PAT; APCu key is per user so one bad actor does
+  not block others.
+- **User without PAT configured is attributed weakly.** The issue appears to be authored by
+  the server-PAT's GitHub identity. Mitigation: authorship prefix with the user's Nextcloud
+  display name and the instance URL; prefix is idempotent so repeat submissions from the
+  same user remain traceable.
+- **XSS via user markdown.** Both rendered roadmap issue bodies AND the submit-modal live
+  preview render markdown from untrusted sources. Mitigation: `DOMPurify` with a strict
+  allowlist — no `<script>`, no `on*` handlers, no `javascript:` URLs, no `<iframe>`, no
+  `<style>`; the config lives in one place in `@conduction/nextcloud-vue` and is reused by
+  both the roadmap list and the preview pane; a Jest test asserts known XSS vectors are
+  stripped.
+- **Admin has not configured any PAT.** Features tab works, Roadmap tab shows "ask your
+  admin" message, POST endpoint returns a clear error with the same remediation hint.
+- **Orphan `specRef` pointing to a removed capability.** A widget/page tags itself with
+  `specRef: 'foo-bar'` but the `foo-bar` capability has since been removed. Mitigation:
+  manifest generator emits a warning when a `specRef` references a slug not present in
+  `docs/features.json`; the Features route UI shows "capability no longer documented" when
+  filtered by an unknown slug.
+- **Docusaurus build breaks if `features.json` is malformed.** Mitigation: the manifest
+  generator validates its own output against a JSON Schema before writing, and fails the
+  build loudly (non-zero exit) if the schema is not satisfied.
+- **Private or archived repositories.** Out of scope for this iteration — documented. The
+  read endpoint will forward GitHub's 404; UI shows empty state with a hint.
+- **Manifest generation drift.** If a spec's `## Purpose` is missing or malformed the
+  generator emits a warning and skips that spec. Invariant test asserts "output is valid
+  JSON with required fields for every included spec."
+- **i18n of spec content.** Feature titles/summaries are not translated. Apps that must ship
+  Dutch-only UX today will see English spec summaries until they translate their specs.
+- **First-time shared navigation-slot component family.** No prior art in
+  `@conduction/nextcloud-vue` for this slot, so API surface decisions here set the pattern.
+  Mitigation: minimal surface, iterate via minor bumps.
+- **Security — PAT leakage.** Both the app-level and user-level PATs MUST never appear in
+  any response body, response header, log line, or error message. Added as an explicit
+  requirement and a PHPUnit test.
+
+## Migration Plan
+
+1. **Backend (OpenRegister).** `GitHubHandler::listIssues` + `GitHubHandler::createIssue`
+   (with user-PAT preferred, server-PAT fallback + attribution prefix) + new
+   `GitHubIssuesController` with `index()` and `create()` actions + route registration
+   (GET with `#[NoCSRFRequired]`, POST without it) + 15-min read cache + APCu submission
+   rate limit + specRef label handling + PHPUnit tests + OpenAPI update.
+2. **Shared library (`@conduction/nextcloud-vue`).** New `CnFeaturesAndRoadmapLink`,
+   `FeaturesAndRoadmapView`, `FeaturesTab`, `RoadmapTab`, `RoadmapItem`,
+   `SuggestFeatureModal`, `useSpecRef()`, strict DOMPurify config export, `marked` +
+   `DOMPurify` wired as peer deps, nl/en i18n, Storybook stories, unit tests, minor bump.
+3. **Build tooling (`@conduction/openspec-manifest`).** CLI that walks
+   `openspec/specs/` (or `./specs/` fallback), filters by status, extracts title +
+   summary, resolves `docsUrl` against `origin/HEAD` default branch, writes
+   `docs/features.json` with schema validation, tests, README.
+4. **Docusaurus package (`@conduction/docusaurus-features`).** New React component +
+   Docusaurus plugin hook that reads `docs/features.json` and renders a public
+   `/features` page with alphabetical ordering matching the in-app view.
+5. **Pilot integration (OpenRegister).** Prebuild script, `/features-roadmap` route,
+   mount `CnFeaturesAndRoadmapLink` above Settings gear, tag 2-3 existing widgets/pages
+   with `specRef` to validate the contract, install `@conduction/docusaurus-features` in
+   OpenRegister's Docusaurus site, Playwright smoke test.
+6. **Docs + rollout prep.** README + migration guide + ADR-019 placeholder in hydra + note
+   in `docs/adr-008-spec-annotations.md` that `specRef` is the runtime equivalent of the
+   static `@spec` PHPDoc annotation.
+7. **(Deferred)** Hydra ADR-019 mandating adoption.
+8. **(Deferred)** Per-app adoption PRs in the other Conduction apps.
+
+## Seed Data
+
+This change introduces no new OpenRegister schemas or registers, so no seed data is
+required. The Roadmap tab's items are fetched live from GitHub via the new proxy endpoint
+and are therefore not seeded in any test dataset. The Features tab's items are computed at
+build time from the host app's own `openspec/specs/` tree, so fixture data for tests is
+simply a small tree of synthetic spec files inside the `@conduction/openspec-manifest`
+package's test directory. For backend integration tests of `GET /api/github/issues`, use
+the real public repository `ConductionNL/openregister` as the query target — it has
+sufficient open-issue volume to exercise the sort + pagination paths. For frontend tests
+of the submit modal, mock the POST and assert the modal closes on success. No live network
+is used in CI.
+
+## Open Questions
+
+All of the originally-surfaced open questions have been resolved by the ten decisions
+applied in this revision. No new genuinely-open questions identified; follow-ups
+(ADR-019 wording, per-app rollout order, optional webpack plugin) are explicitly deferred
+and tracked as non-goals of this change.
diff --git a/openspec/changes/add-features-roadmap-menu/proposal.md b/openspec/changes/add-features-roadmap-menu/proposal.md
new file mode 100644
index 0000000000..4cd3268b21
--- /dev/null
+++ b/openspec/changes/add-features-roadmap-menu/proposal.md
@@ -0,0 +1,132 @@
+# Add Features & Roadmap Menu
+
+## Why
+
+Operators and end-users of Conduction Nextcloud apps currently have no in-product way to see
+(a) what the app can do today, (b) what is coming next, and (c) how to suggest what they want
+built. Documentation lives in README files and GitHub issue trackers that non-developers never
+visit. Every app has the same gap, and every app has the same two sources of truth already:
+its `openspec/specs/` tree (what is implemented) and its GitHub repository (what is planned,
+via open issues). We will bind those two sources to a single, shared UI element mounted in the
+`NcAppNavigationSettings` sidebar slot — above the existing Settings gear — so that every
+Conduction app gets a consistent "Features & Roadmap" entry without inventing a new storage
+model or synchronization job.
+
+The critical value, explicitly called out by the user as "the most important part," is the
+user-generated feature request path: any authenticated user, from inside the app (either the
+dedicated route or any widget/page that opted into the `specRef` contract), can file a feature
+request that lands directly as a GitHub issue on the app's repo, routed via their own GitHub
+token when present and via the server's app-level token (with authorship prefix) as fallback.
+
+## What Changes
+
+- Extend OpenRegister's existing `GitHubHandler` (ADR-011 utility reuse) with `listIssues()`
+  and `createIssue()` methods. `createIssue()` prefers the user's own PAT stored at
+  `openregister::github_token` (IConfig) and falls back to the app-level PAT at
+  `openregister::github_api_token` (IAppConfig); when falling back, it prepends an attribution
+  prefix to the issue body so authorship is preserved.
+- Add a new `GitHubIssuesController` exposing:
+  - `GET /api/github/issues` — a thin, cached proxy to GitHub's issues search endpoint.
+    Carries `#[NoCSRFRequired]` since it is a pure read with no side effects.
+  - `POST /api/github/issues` — accepts `{repo, title, body, specRef?}` and creates a GitHub
+    issue on the app's repo. MUST enforce CSRF (no `#[NoCSRFRequired]` attribute). Subject to
+    per-user APCu-backed rate limit of 1 submission per 60 seconds.
+- Add a new shared Vue component family to `@conduction/nextcloud-vue`:
+  - `CnFeaturesAndRoadmapLink` — an `NcAppNavigationItem` that navigates to a dedicated route.
+  - `FeaturesAndRoadmapView` — the full-route view with Features, Roadmap, and a header
+    "Suggest feature" button.
+  - `SuggestFeatureModal` — a modal form with live markdown preview, title + body fields, and
+    a hidden `specRef` field pre-filled when launched from a widget/page context.
+  - `useSpecRef()` — a composable that reads `specRef` from the active component's
+    `defineOptions({ specRef })` / Options-API component option OR from Vue Router's
+    `meta.specRef` on the active route.
+  - Roadmap item bodies render via `marked` + `DOMPurify` (strict allowlist: no `<script>`,
+    no `on*` handlers, no `javascript:` URLs, no `<iframe>`).
+  - A label blocklist filters out Hydra pipeline / workflow labels so only user-facing labels
+    render on each roadmap item.
+- Add a new standalone build-tool package `@conduction/openspec-manifest` that walks an app's
+  `openspec/specs/*/spec.md` tree (preferring that path, falling back to `./specs/` for
+  legacy layouts), parses YAML frontmatter, filters to `status ∈ {implemented, reviewed}`,
+  extracts the H1 title and the `## Purpose` summary, resolves `docsUrl` against the repo's
+  default branch (`origin/HEAD`, not the currently checked-out branch), and emits
+  `docs/features.json` — committed to git (NOT gitignored) — to be bundled by the app's
+  build AND consumed by the app's Docusaurus site. CLI only in this iteration; a webpack
+  plugin is deferred.
+- Add a new shared Docusaurus package `@conduction/docusaurus-features` that reads
+  `docs/features.json` and renders a public features page on the app's Docusaurus site,
+  reusing the same ordering and visual style as the in-app component (within Docusaurus
+  theming constraints).
+- Pilot the end-to-end wiring inside OpenRegister itself: add the prebuild step, add the
+  `/features-roadmap` route, mount `CnFeaturesAndRoadmapLink` in OpenRegister's own
+  `MainMenu.vue`, tag 2-3 existing widgets/pages with `specRef` to validate the contract,
+  install `@conduction/docusaurus-features` in OpenRegister's Docusaurus site, ship a small
+  smoke test.
+- Add cross-repo documentation: README in the new component package, short migration guide
+  for app maintainers, placeholder reference to a future hydra ADR-019 that will mandate
+  fleet-wide adoption, note in `docs/adr-008-spec-annotations.md` that `specRef` is the
+  runtime equivalent of the static `@spec` annotation.
+
+Out of scope for this change (follow-ups, tracked separately):
+
+- GitHub Discussions integration (user chose Issues, not Discussions).
+- "Accept feature → specter spec proposal" wiring.
+- Company-wide ADR-019 in `hydra/openspec/` mandating adoption by every app.
+- Adoption PRs in the other Conduction apps (opencatalogi, docudesk, openconnector, mydash,
+  zaakafhandelapp, procest, pipelinq, softwarecatalog, larpingapp, decidesk, nldesign).
+- Webpack plugin wrapper for the manifest generator.
+
+## Capabilities
+
+### New Capabilities
+
+- **`github-issue-proxy`** — A thin OpenRegister backend that (a) proxies open GitHub issues
+  (sorted by reactions) for a given public repository and (b) creates new GitHub issues on
+  behalf of authenticated users. Uses the user's per-user GitHub PAT when present and falls
+  back to the app-level PAT with an authorship prefix when the user has none. Handles
+  rate-limit and missing-PAT gracefully, enforces per-user submission rate limiting, and
+  applies `specRef:<slug>` labels when the submitter declared a capability context.
+- **`features-roadmap-menu`** — The cross-repo UX and build-time contract that ties shipped
+  features (extracted from OpenSpec specs, rendered both in-app and on the app's Docusaurus
+  site) and roadmap items (GitHub issues via the proxy, with full markdown rendering and
+  label filtering) into a single navigation entry and dedicated route, with an
+  action-menu-driven submission modal available from any widget or page that declared a
+  `specRef`. Implementation spans the shared `@conduction/nextcloud-vue` component family,
+  the `@conduction/openspec-manifest` build tool, and the `@conduction/docusaurus-features`
+  Docusaurus package.
+
+### Modified Capabilities
+
+None in this change. (Future ADR-019 in hydra will create a company-wide capability mandating
+adoption — deliberately deferred.)
+
+## Impact
+
+- **Reuses ADR-011 utilities.** The GitHub proxy extends the existing `GitHubHandler` class
+  (`lib/Service/Configuration/GitHubHandler.php`) with two new methods — no new HTTP client,
+  no new retry/rate-limit machinery. The controller delegates entirely to the handler.
+- **New behavior: submissions write to the app's GitHub repo.** This is the first OpenRegister
+  feature that creates resources on an external system on behalf of an end-user. Traceability
+  is guaranteed by the authorship prefix on server-PAT fallback.
+- **OpenRegister's existing per-user GitHub token store (`openregister::github_token`) gains
+  a new consumer.** Previously only used for other GitHub integrations; now also read by
+  `createIssue()` as the preferred credential.
+- **No new OpenRegister schemas, registers or data stores.** The proxy is stateless aside
+  from a 15-minute in-memory response cache for reads and an APCu rate-limit key
+  (`openregister.feature_submission:<user_id>`) for writes. Features come from a build-time
+  JSON manifest bundled into each app's JS — no backend read path for features at all.
+- **First cross-repo shared-library navigation component family.** `@conduction/nextcloud-vue`
+  today exports only `CnSettingsCard` / `CnSettingsSection`. The new component family
+  (`CnFeaturesAndRoadmapLink`, `FeaturesAndRoadmapView`, `SuggestFeatureModal`,
+  `useSpecRef`) sets the pattern for future additions (help, support, feedback).
+- **First shared Docusaurus component from Conduction.** `@conduction/docusaurus-features` is
+  a new package; visual parity with in-app component within Docusaurus theming constraints.
+- **Graceful degradation.** No PAT configured → GET endpoint returns `200` with an empty
+  items array and a `hint` code; UI renders a muted "roadmap temporarily unavailable"
+  message without blocking the Features tab. POST endpoint without PAT returns a clear
+  401/403 with an admin-remediation hint.
+- **i18n.** Component ships with Dutch (nl) and English (en) strings for its chrome (route
+  title, tab labels, modal fields, empty states, toasts, error messages). Feature titles /
+  summaries pass through unchanged because spec files are the single source of truth.
+- **Fleet rollout deliberately deferred.** Only OpenRegister adopts the component in this
+  change. The other apps will adopt under a separate ADR-019 + rollout plan — this limits
+  the blast radius of a first-time shared-component release.
diff --git a/openspec/changes/add-features-roadmap-menu/specs/features-roadmap-menu/spec.md b/openspec/changes/add-features-roadmap-menu/specs/features-roadmap-menu/spec.md
new file mode 100644
index 0000000000..f24d6be6bb
--- /dev/null
+++ b/openspec/changes/add-features-roadmap-menu/specs/features-roadmap-menu/spec.md
@@ -0,0 +1,428 @@
+---
+status: proposed
+capability: features-roadmap-menu
+---
+
+# Features and Roadmap Menu
+
+## Purpose
+
+Define a cross-repo UX contract, submission contract, and build-time extraction contract
+that lets every Conduction Nextcloud app mount a single "Features & Roadmap" entry in its
+navigation-settings slot that navigates to a dedicated route with two tabs — shipped
+capabilities (extracted from the app's own OpenSpec specs at build time) and the live
+roadmap (open GitHub issues via OpenRegister's proxy) — plus a "Suggest feature"
+submission modal available from (a) the route header and (b) any widget or page that opts
+in via the ADR-008-aligned `specRef` declaration. The same `docs/features.json` manifest
+also powers a public features page on the app's Docusaurus site via the shared
+`@conduction/docusaurus-features` package. The capability specifies component APIs, the
+manifest file shape, the extraction rules for OpenSpec specs, the submission UX, i18n
+requirements, and degraded-state rendering. Implementation lives in
+`@conduction/nextcloud-vue` (the in-app component family),
+`@conduction/openspec-manifest` (the extractor), and `@conduction/docusaurus-features`
+(the public page), all of which are new additions under this change.
+
+## ADDED Requirements
+
+### Requirement: Full route, not side panel
+
+The Features & Roadmap surface SHALL be implemented as a dedicated Vue route (e.g.
+`/features-roadmap`) registered by the host app. The `NcAppNavigationSettings` entry SHALL
+be an `<NcAppNavigationItem>` (exposed by `@conduction/nextcloud-vue` as
+`CnFeaturesAndRoadmapLink`) that navigates to this route on click. The route view SHALL
+NOT be implemented as a side panel or modal.
+
+#### Scenario: Clicking the nav entry navigates to the route
+
+- **WHEN** a user clicks the "Features & Roadmap" item in `NcAppNavigationSettings`
+- **THEN** the browser SHALL navigate to the registered route (e.g. `/features-roadmap`)
+- **AND** the route view SHALL render in the main content area, not as an overlay
+
+### Requirement: Route entry above settings gear
+
+The `CnFeaturesAndRoadmapLink` component SHALL be positioned as the first child of `<NcAppNavigationSettings>` in a host app's `src/navigation/MainMenu.vue` (or equivalent), above any existing `<NcAppNavigationItem>` children such as the Settings gear.
+
+#### Scenario: Mounted above Settings in host app
+
+- **WHEN** a host app places `<CnFeaturesAndRoadmapLink>` as the first child of
+  `<NcAppNavigationSettings>` and `<NcAppNavigationItem>` for Settings as the second child
+- **THEN** the Features & Roadmap row SHALL render above the Settings row in the rendered
+  DOM
+
+### Requirement: Two tabs with i18n labels
+
+The route view SHALL render two tabs labelled "Features" and "Roadmap" in English, or
+"Functies" and "Planning" in Dutch. The tab labels, empty-state messages, modal fields,
+error messages, and toasts SHALL be translatable via Nextcloud's `t()` / `n()` helpers.
+English (en) and Dutch (nl) MUST be shipped at minimum.
+
+#### Scenario: Dutch locale shows Dutch tab labels
+
+- **WHEN** the Nextcloud UI locale is `nl`
+- **THEN** the tabs SHALL read "Functies" and "Planning"
+
+#### Scenario: English locale shows English tab labels
+
+- **WHEN** the Nextcloud UI locale is `en`
+- **THEN** the tabs SHALL read "Features" and "Roadmap"
+
+### Requirement: Features list ordering
+
+Features in the Features tab SHALL render in alphabetical order by `title`, case-
+insensitively, using a locale-aware comparator. Ties SHALL fall back to the source order in
+`docs/features.json`. The Docusaurus features page SHALL match this ordering exactly.
+
+#### Scenario: Alphabetical ordering
+
+- **WHEN** `features` contains entries with titles `["Zaken", "Archivering", "mock-registers"]`
+- **THEN** the rendered order in the Features tab SHALL be
+  `["Archivering", "mock-registers", "Zaken"]`
+
+### Requirement: Roadmap sorted by reaction count
+
+Within the Roadmap tab, items SHALL be rendered in the order returned by the proxy, which
+is `reactions.+1` descending. The reaction count SHALL be visible as a numeric badge on
+each item. Ties SHALL fall back to `created_at` descending.
+
+#### Scenario: Highest-reaction issue renders first
+
+- **WHEN** the proxy returns items with `reactions.+1` values of `[7, 15, 3]`
+- **THEN** the rendered order SHALL be `[15, 7, 3]`
+
+### Requirement: Full markdown rendering with XSS protection
+
+Each roadmap item's body SHALL be rendered as full GitHub-flavored markdown using the
+`marked` library. Rendered output MUST be sanitized with `DOMPurify` using a strict
+allowlist config that MUST exclude `<script>`, all `on*` attributes, `javascript:` URLs,
+`<iframe>`, and `<style>`. The same sanitizer configuration SHALL be used by the
+`SuggestFeatureModal` live preview.
+
+#### Scenario: Markdown body renders as formatted HTML
+
+- **WHEN** a roadmap issue body is `"**bold** and *italic*\n\n- item one\n- item two"`
+- **THEN** the rendered DOM SHALL contain a `<strong>` element wrapping "bold", an `<em>`
+  element wrapping "italic", and a `<ul>` with two `<li>` children
+
+#### Scenario: XSS in body is stripped
+
+- **WHEN** a roadmap issue body is `"<script>alert('x')</script><img src=x onerror=alert(1)>"`
+- **THEN** the rendered DOM SHALL NOT contain any `<script>` element
+- **AND** the rendered `<img>` element (if present) SHALL NOT carry an `onerror`
+  attribute
+
+### Requirement: Label blocklist
+
+The roadmap view SHALL filter out any issue labels whose name matches any of the
+following regular expressions: `^build:`, `^code-review:`, `^security-review:`,
+`^applier:`, `^retry:`, `^rebuild:`, `^fix:`, `^fix-iteration:`, `^build-retry:`,
+`^ready-`, `^needs-input$`, `^yolo$`, `^openspec$`, `^agent-maxed-out$`,
+`^pipeline-active$`, `^done$`, `:queued$`, `:running$`, `:pass$`, `:fail$`. Labels that
+do not match any blocklist pattern SHALL render with their GitHub-native color from the
+proxy response. The blocklist SHALL live in a single named constant exported by
+`@conduction/nextcloud-vue` so it is documented and easy to extend.
+
+#### Scenario: Pipeline labels are hidden
+
+- **WHEN** an issue carries labels `["enhancement", "build:running", "ready-for-code-review", "accessibility"]`
+- **THEN** the rendered label chips SHALL be exactly `["enhancement", "accessibility"]`
+
+#### Scenario: Label retains its GitHub color
+
+- **WHEN** an issue carries a label `{name: "enhancement", color: "a2eeef"}`
+- **THEN** the rendered chip SHALL use `#a2eeef` as its background or border color
+
+### Requirement: Widget specRef declaration
+
+Vue widgets SHALL declare a capability reference via `defineOptions({ specRef: '<slug>' })` (Composition API) or a component option `specRef: '<slug>'` (Options API), where `<slug>` MUST be a kebab-case capability slug identical in convention to ADR-008 `@spec` PHPDoc annotations on the backend. Widgets without a `specRef` declaration are unaffected by this contract.
+
+#### Scenario: Composition API declaration is detected
+
+- **WHEN** a Vue widget uses `<script setup>` and calls `defineOptions({ specRef: 'catalog-management' })`
+- **AND** the composable `useSpecRef()` is invoked within that widget's scope
+- **THEN** `useSpecRef()` SHALL return `'catalog-management'`
+
+### Requirement: Page specRef via route meta
+
+The `useSpecRef()` composable SHALL support declaring a page's capability reference via the Vue Router `meta.specRef` field on the active route; when invoked inside a page component that has no component-level `specRef`, it SHALL fall back to `route.meta.specRef`.
+
+#### Scenario: Route meta fallback
+
+- **WHEN** the active route is defined with `meta: { specRef: 'search-indexing' }`
+- **AND** the rendered component has no `specRef` option
+- **THEN** `useSpecRef()` SHALL return `'search-indexing'`
+
+### Requirement: Action menu integration
+
+Widgets and pages that declared a `specRef` SHALL expose a "Suggest feature" item in their
+`NcActions` menu. Clicking the item SHALL open the `SuggestFeatureModal` pre-filled with
+the active `specRef` in a hidden field. The helper exposed by `@conduction/nextcloud-vue`
+to inject this action into an existing `NcActions` SHALL be opt-in (available only when a
+non-empty `specRef` is present).
+
+#### Scenario: Widget with specRef exposes the action
+
+- **WHEN** a widget declares `specRef: 'catalog-management'` AND mounts an `NcActions` that
+  wires in the shared helper
+- **THEN** the action menu SHALL include an item labelled "Suggest feature"
+- **AND** clicking it SHALL open `SuggestFeatureModal` with hidden field
+  `specRef="catalog-management"` pre-populated
+
+#### Scenario: Widget without specRef does NOT expose the action
+
+- **WHEN** a widget has no `specRef` declaration
+- **THEN** the action menu SHALL NOT include a "Suggest feature" item
+
+### Requirement: Suggest feature modal
+
+A modal form `SuggestFeatureModal` SHALL be available from (a) the Features & Roadmap
+route header as a "Suggest feature" button, and (b) any widget or page that declared a
+`specRef` via its action menu. The modal SHALL include: a required title field (3-200
+chars), a required markdown body textarea (min 10 chars), a live preview toggle that
+renders the body through the same `marked` + `DOMPurify` pipeline as roadmap items, a
+Submit button, and a Cancel button. When launched from a `specRef` context, the modal
+SHALL include the `specRef` as a hidden field. Submit SHALL POST to `/api/github/issues`
+with the CSRF token included.
+
+#### Scenario: Route-header launch has no specRef
+
+- **WHEN** a user clicks "Suggest feature" from the route header
+- **THEN** the modal SHALL open without any pre-filled `specRef`
+
+#### Scenario: Widget launch pre-fills specRef
+
+- **WHEN** a user clicks "Suggest feature" from a widget with `specRef: "catalog-management"`
+- **THEN** the modal SHALL open with hidden field `specRef="catalog-management"`
+
+#### Scenario: Submit requires title and body
+
+- **WHEN** a user opens the modal and submits with empty title or a body shorter than 10
+  chars
+- **THEN** the Submit button SHALL be disabled OR SHALL show inline validation errors
+- **AND** no POST SHALL be issued
+
+### Requirement: Submission success feedback
+
+On a successful submission (HTTP 201 from the endpoint), the modal SHALL close and a
+Nextcloud toast SHALL appear with the localized text "Feature request submitted" (en) /
+"Functieverzoek verzonden" (nl) and a clickable link to the issue's `html_url` opening in
+a new tab with `rel="noopener noreferrer"`.
+
+#### Scenario: Success toast contains link
+
+- **WHEN** the submission endpoint responds HTTP 201 with `{number: 42, html_url: "https://github.com/.../42"}`
+- **THEN** the modal SHALL close
+- **AND** a toast SHALL appear containing the localized success message AND a link whose
+  `href` equals `https://github.com/.../42` and whose `target` is `_blank`
+
+### Requirement: Submission error handling
+
+The modal SHALL handle submission errors as follows:
+
+- On HTTP 401, the UI SHALL show a localized "Please sign in to submit a feature request"
+  message and SHALL NOT retry automatically.
+- On HTTP 429, the UI SHALL show a localized "Please wait <N>s before submitting another
+  request" message using the `retry_after` value from the response body.
+- On HTTP 503 with `error: "github_pat_not_configured"`, the UI SHALL show a localized
+  "Feature submission is not configured on this instance — please ask your administrator"
+  message.
+- On HTTP 500, network error, or any other failure mode, the UI SHALL show a localized
+  "Submission failed, try again" message and SHALL surface a Retry button that re-attempts
+  the POST with the same title, body, and specRef.
+
+#### Scenario: Rate-limited submission
+
+- **WHEN** the endpoint responds HTTP 429 with body `{error: "rate_limited", retry_after: 45}`
+- **THEN** the modal SHALL show the rate-limit message containing "45" as the remaining
+  seconds
+
+#### Scenario: Generic failure offers retry
+
+- **WHEN** the endpoint responds HTTP 500
+- **THEN** the modal SHALL show the generic failure message
+- **AND** a Retry button SHALL be visible
+
+### Requirement: specRef-aware filtering
+
+The Features & Roadmap view SHALL filter its content by `specRef` when opened from a widget or page context with a known slug: the Features tab SHALL filter to features whose capability slug equals the `specRef`, and the Roadmap tab SHALL filter to issues carrying a label named exactly `specRef:<slug>`. When opened directly with no `specRef` context, no filtering SHALL be applied.
+
+#### Scenario: Filtered from widget context
+
+- **WHEN** the user opens the route with query parameter `?specRef=catalog-management`
+- **THEN** the Features tab SHALL show only features whose slug equals
+  `catalog-management`
+- **AND** the Roadmap tab SHALL show only issues labelled `specRef:catalog-management`
+
+### Requirement: Manifest output location
+
+The `@conduction/openspec-manifest` CLI SHALL write its manifest to `docs/features.json`
+relative to the working directory. This file MUST be committed to git (it MUST NOT be
+listed in `.gitignore`) so that the same artifact powers both the in-app JS bundle AND
+the app's Docusaurus public features page.
+
+#### Scenario: Default output path
+
+- **WHEN** the CLI is invoked with no arguments in a project with `openspec/specs/foo/spec.md`
+- **THEN** the CLI SHALL write `docs/features.json` relative to the working directory
+
+### Requirement: Manifest content shape
+
+`docs/features.json` SHALL be a JSON object of the shape
+`{"schemaVersion": 1, "generatedAt": "<ISO-8601 timestamp>", "features": [...]}`. Each
+entry in `features` SHALL have the keys `slug`, `title`, `summary`, `status`, `docsUrl`,
+and optionally `category`. The file SHALL be pretty-printed with two-space indent. The
+`generatedAt` value SHALL be the only non-deterministic field; all other content SHALL be
+deterministic given the same spec inputs.
+
+#### Scenario: Output shape
+
+- **WHEN** the CLI emits a manifest
+- **THEN** the top-level JSON SHALL have keys `schemaVersion`, `generatedAt`, and
+  `features`
+- **AND** `schemaVersion` SHALL equal `1`
+
+### Requirement: Manifest spec-dir discovery
+
+The CLI SHALL prefer `./openspec/specs/*/spec.md` when the directory exists. It SHALL fall
+back to `./specs/*/spec.md` when `./openspec/` is absent. When both directories are
+present, the CLI SHALL emit a console warning identifying the ambiguity and SHALL process
+only `./openspec/specs/`.
+
+#### Scenario: Standard OpenSpec layout
+
+- **WHEN** the CLI runs in a directory with `./openspec/specs/foo/spec.md` and no
+  `./specs/`
+- **THEN** it SHALL discover `./openspec/specs/foo/spec.md`
+
+#### Scenario: Legacy layout
+
+- **WHEN** the CLI runs in a directory with `./specs/foo/spec.md` and no `./openspec/`
+- **THEN** it SHALL discover `./specs/foo/spec.md`
+
+#### Scenario: Both directories present emits warning
+
+- **WHEN** the CLI runs in a directory containing both `./openspec/specs/` and `./specs/`
+- **THEN** it SHALL emit a warning on stderr naming both paths
+- **AND** it SHALL process only `./openspec/specs/`
+
+### Requirement: Feature status filter
+
+The CLI SHALL include in the manifest only specs whose frontmatter `status` is
+`implemented` or `reviewed`. Specs with `status: redirect`, `status: proposed`,
+`status: draft`, or any other value SHALL be excluded.
+
+#### Scenario: Only implemented and reviewed are included
+
+- **WHEN** the CLI processes specs with statuses
+  `["implemented", "reviewed", "proposed", "redirect", "draft"]`
+- **THEN** the emitted `features` array SHALL contain exactly two entries corresponding to
+  the `implemented` and `reviewed` specs
+
+### Requirement: Manifest title and summary extraction
+
+For each included spec, the CLI SHALL extract the first H1 (`# Title`) immediately
+following the frontmatter as `title`, and the first paragraph under the first `## Purpose`
+section as `summary`. The `slug` SHALL be the enclosing spec directory name. When either
+title or purpose paragraph is missing, the spec SHALL be skipped with a console warning.
+
+#### Scenario: Well-formed spec yields title, slug, and summary
+
+- **WHEN** a spec at `openspec/specs/computed-fields/spec.md` has `# Computed Fields` as
+  its H1 and a `## Purpose` paragraph beginning "Expose derived values on objects without
+  duplicating storage."
+- **THEN** the manifest entry SHALL contain
+  `{"slug": "computed-fields", "title": "Computed Fields", "summary": "Expose derived values on objects without duplicating storage."}`
+
+### Requirement: Manifest default docsUrl
+
+The CLI SHALL default `docsUrl` for each entry to
+`https://github.com/<repo>/blob/<defaultBranch>/openspec/specs/<slug>/spec.md`, where
+`<defaultBranch>` is resolved via `git symbolic-ref refs/remotes/origin/HEAD` so the URL
+always points to the repo's default branch and NEVER to the currently checked-out branch.
+When the git remote is not a GitHub URL or the default branch cannot be determined,
+`docsUrl` SHALL be omitted from the entry and a console warning SHALL be emitted.
+
+#### Scenario: docsUrl resolves against origin default branch
+
+- **WHEN** the repo origin is `git@github.com:ConductionNL/openregister.git`, the default
+  branch resolved from `origin/HEAD` is `main`, the currently checked-out local branch is
+  `feature/something-unrelated`, and a spec lives at
+  `openspec/specs/computed-fields/spec.md`
+- **THEN** the entry's `docsUrl` SHALL be
+  `https://github.com/ConductionNL/openregister/blob/main/openspec/specs/computed-fields/spec.md`
+- **AND** the entry's `docsUrl` SHALL NOT reference the local checked-out branch
+
+### Requirement: Manifest frontmatter docsUrl override
+
+When a spec's YAML frontmatter contains a `docsUrl:` key, that value SHALL override the
+default computed `docsUrl` verbatim.
+
+#### Scenario: Frontmatter override wins
+
+- **WHEN** a spec declares `docsUrl: https://docs.example/foo` in its frontmatter
+- **THEN** the entry's `docsUrl` SHALL be `https://docs.example/foo`
+
+### Requirement: Docusaurus features page
+
+The `@conduction/docusaurus-features` npm package SHALL export a React component
+`<FeaturesPage />` and a Docusaurus plugin hook that reads `docs/features.json` at
+build time and renders a public `/features` page on the app's Docusaurus site. The page
+SHALL render features in the same alphabetical order as the in-app component and SHALL
+match the in-app visual style as closely as Docusaurus theming allows.
+
+#### Scenario: Public page renders the manifest
+
+- **WHEN** a host app installs `@conduction/docusaurus-features`, configures the plugin
+  in `docusaurus.config.js`, and builds the Docusaurus site with a non-empty
+  `docs/features.json`
+- **THEN** the built site SHALL include a `/features` page
+- **AND** the rendered feature titles SHALL match `docs/features.json` in alphabetical
+  order by title
+
+### Requirement: Empty states
+
+The Features tab and Roadmap tab SHALL render localized, muted empty-state messages for every degraded condition instead of exposing technical errors. When `docs/features.json` contains an empty `features` array, both the in-app Features tab AND the Docusaurus public features page SHALL render "No features documented yet" (en) / "Nog geen functies gedocumenteerd" (nl). When the roadmap proxy returns `{items: [], hint: "github_pat_not_configured"}`, the Roadmap tab SHALL render "Roadmap currently unavailable" (en) / "Planning momenteel niet beschikbaar" (nl) with an admin-remediation hint. When the proxy returns an empty `items` array without a `hint`, the tab SHALL render "No roadmap items yet" (en) / "Nog geen planningsitems" (nl). When the proxy returns HTTP 429, the tab SHALL render "Roadmap rate-limited, try again later" (en) / "Planning tijdelijk afgeknepen, probeer het later opnieuw" (nl).
+
+#### Scenario: Empty features manifest
+
+- **WHEN** `docs/features.json` has `features: []`
+- **THEN** the Features tab SHALL render the "No features documented yet" message
+- **AND** the Docusaurus `/features` page SHALL render the same message
+
+#### Scenario: PAT not configured roadmap
+
+- **WHEN** the proxy returns `items: []` with `hint: "github_pat_not_configured"`
+- **THEN** the Roadmap tab SHALL render the "Roadmap currently unavailable" message
+
+### Requirement: i18n
+
+All UI strings — route title, tab labels, modal field labels, modal placeholders, empty states, toasts, error messages, and button labels — MUST be translatable via Nextcloud's `t()` / `n()` helpers, and Dutch (nl) plus English (en) translations MUST be shipped at minimum. The Docusaurus public page SHALL use Docusaurus's native i18n infrastructure and MUST ship nl + en at minimum.
+
+#### Scenario: Nl locale translates all route chrome
+
+- **WHEN** the Nextcloud UI locale is `nl` and the user opens the Features & Roadmap route
+- **THEN** the route title, both tab labels, the "Suggest feature" button, and the
+  modal's field labels SHALL all render in Dutch
+
+### Requirement: Link safety
+
+All external links rendered by the in-app component and the Docusaurus public page MUST open with `target="_blank"` and `rel="noopener noreferrer"` attributes. This SHALL include feature `docsUrl` links, roadmap `html_url` links, and links in the success toast returned after a submission.
+
+#### Scenario: Feature docsUrl link safety
+
+- **WHEN** a feature has `docsUrl: "https://example.invalid/spec"`
+- **THEN** the rendered DOM SHALL wrap the feature in or contain an anchor with
+  `target="_blank"` and `rel="noopener noreferrer"`
+
+### Requirement: Manifest consumption in app build
+
+The host app's build (webpack or vite) SHALL import `docs/features.json` and pass its
+`features` array to the `FeaturesAndRoadmapView`. The `@conduction/openspec-manifest` CLI
+SHALL be wired as a `prebuild` npm script so that every `npm run build` regenerates the
+manifest before the application build runs.
+
+#### Scenario: Prebuild runs automatically
+
+- **WHEN** `npm run build` is invoked in a host app with
+  `"prebuild": "openspec-manifest build"`
+- **THEN** `docs/features.json` SHALL be regenerated before webpack / vite runs
+- **AND** the bundled JS SHALL contain the current manifest contents
diff --git a/openspec/changes/add-features-roadmap-menu/specs/github-issue-proxy/spec.md b/openspec/changes/add-features-roadmap-menu/specs/github-issue-proxy/spec.md
new file mode 100644
index 0000000000..27c5b00bc6
--- /dev/null
+++ b/openspec/changes/add-features-roadmap-menu/specs/github-issue-proxy/spec.md
@@ -0,0 +1,327 @@
+---
+status: proposed
+capability: github-issue-proxy
+---
+
+# GitHub Issue Proxy
+
+## Purpose
+
+Expose a thin, cached, server-side proxy over GitHub's issues API so every Conduction
+Nextcloud app can surface its own roadmap (open issues, sorted by reactions) AND let
+authenticated users file new feature requests that land directly as GitHub issues on the
+app's repo. The proxy reuses OpenRegister's existing `GitHubHandler` utility and both
+existing PAT stores: the per-user `openregister::github_token` (IConfig) preferred for
+authorship, and the app-level `openregister::github_api_token` (IAppConfig) used as a
+fallback for reads and for submissions when the user has no personal PAT.
+
+## ADDED Requirements
+
+### Requirement: Issues list endpoint
+
+OpenRegister SHALL expose `GET /api/github/issues` that accepts the query parameters `repo`
+(required, format `<owner>/<repo>`), `state` (optional, default `open`), `sort` (optional,
+default `reactions-+1`), and `per_page` (optional integer, default 30, maximum 100). The
+endpoint SHALL return a JSON response containing an `items` array of issue objects fetched
+from GitHub for the given repository, with sensitive data stripped. The endpoint MUST carry
+`#[NoCSRFRequired]` since it is a pure read with no side effects.
+
+#### Scenario: Successful fetch of open issues
+
+- **WHEN** an authenticated Nextcloud user requests `GET /api/github/issues?repo=ConductionNL/openregister`
+- **AND** the app-level GitHub PAT is configured
+- **THEN** the endpoint SHALL return HTTP 200 with `{"items": [...], "total": N}`
+- **AND** each item SHALL contain `number`, `title`, `body`, `html_url`, `user.login`,
+  `user.avatar_url`, `reactions.total_count`, `reactions.+1`, `created_at`, `updated_at`, and
+  `labels[].{name,color}`
+- **AND** items SHALL be sorted by `reactions-+1` descending
+
+#### Scenario: Missing repo parameter
+
+- **WHEN** a user requests `GET /api/github/issues` with no `repo` query parameter
+- **THEN** the endpoint SHALL return HTTP 400 with a structured error code `repo_required`
+
+### Requirement: Issue creation endpoint
+
+OpenRegister SHALL expose `POST /api/github/issues` that accepts a JSON body of the shape
+`{repo: string, title: string, body: string, specRef?: string}` and creates a GitHub issue
+on the named repository. The endpoint MUST enforce CSRF protection (no `#[NoCSRFRequired]`
+attribute). The endpoint SHALL validate that `repo` matches `^[\w.-]+/[\w.-]+$`, that
+`title` is 3-200 characters, and that `body` is at least 10 characters; violations SHALL
+yield HTTP 400 with a structured error code and SHALL NOT issue an outbound GitHub request.
+
+#### Scenario: Successful submission
+
+- **WHEN** an authenticated user POSTs `{repo: "ConductionNL/openregister", title: "Add dark mode", body: "A longer description of the feature idea."}` with a valid CSRF token
+- **AND** either the user or server GitHub PAT is configured
+- **AND** the user is not currently rate-limited
+- **THEN** the endpoint SHALL issue an authenticated POST to GitHub's
+  `/repos/{owner}/{repo}/issues` endpoint
+- **AND** it SHALL return HTTP 201 with `{number, html_url, state}`
+
+#### Scenario: Missing CSRF token
+
+- **WHEN** an authenticated user POSTs to `/api/github/issues` without a CSRF token
+- **THEN** Nextcloud's middleware SHALL return HTTP 412 (or the configured CSRF error
+  status) before the controller runs
+
+#### Scenario: Title too short
+
+- **WHEN** a user POSTs `{repo: "ConductionNL/openregister", title: "Hi", body: "A valid body at least ten chars."}`
+- **THEN** the endpoint SHALL return HTTP 400 with error code `title_invalid_length`
+- **AND** no outbound GitHub request SHALL be issued
+
+#### Scenario: Body too short
+
+- **WHEN** a user POSTs `{repo: "ConductionNL/openregister", title: "A valid title", body: "short"}`
+- **THEN** the endpoint SHALL return HTTP 400 with error code `body_invalid_length`
+- **AND** no outbound GitHub request SHALL be issued
+
+### Requirement: Authorship fallback
+
+`GitHubHandler::createIssue` SHALL prefer the authenticated user's stored per-user token
+read from `IConfig` key `openregister::github_token` when present. When that value is empty
+or absent, it SHALL fall back to the app-level PAT read from `IAppConfig` key
+`openregister::github_api_token`. When falling back, the handler SHALL prefix the body sent
+to GitHub with the attribution block:
+
+```
+> Submitted by **<display_name>** via <instance_url>
+
+---
+
+```
+
+where `<display_name>` is the Nextcloud user's display name and `<instance_url>` is the
+Nextcloud base URL. When the user-level PAT is used, no attribution prefix SHALL be added
+and the issue SHALL be authored as the user's own GitHub identity.
+
+#### Scenario: User PAT present
+
+- **WHEN** the submitting user has `openregister::github_token` set to a valid token
+- **THEN** the outbound POST SHALL carry that token
+- **AND** the issue body sent to GitHub SHALL be the user's body verbatim, with no
+  attribution prefix
+
+#### Scenario: User PAT absent, server PAT present
+
+- **WHEN** the submitting user has no per-user token
+- **AND** the app-level `openregister::github_api_token` is set
+- **THEN** the outbound POST SHALL carry the app-level token
+- **AND** the issue body sent to GitHub SHALL begin with
+  `> Submitted by **<display_name>** via <instance_url>\n\n---\n\n` followed by the user's
+  body verbatim
+
+#### Scenario: Both PATs absent
+
+- **WHEN** neither the user PAT nor the app-level PAT is configured
+- **THEN** the endpoint SHALL return HTTP 503 with error code
+  `github_pat_not_configured`
+- **AND** no outbound GitHub request SHALL be issued
+
+### Requirement: specRef handling on submission
+
+When the request body includes a non-empty `specRef` value, the controller SHALL append the
+block `\n\n---\nRelated capability: `<specRef>`\n` to the issue body sent to GitHub AND
+SHALL apply a `specRef:<slug>` label to the created issue. The label SHALL be added even if
+the label does not yet exist on the target repository (GitHub creates it on-demand).
+
+#### Scenario: specRef provided
+
+- **WHEN** a user submits `{repo: "ConductionNL/openregister", title: "A title", body: "A valid body.", specRef: "catalog-management"}`
+- **THEN** the body sent to GitHub SHALL end with
+  `\n\n---\nRelated capability: `catalog-management`\n`
+- **AND** the created issue SHALL carry a label named `specRef:catalog-management`
+
+#### Scenario: specRef omitted
+
+- **WHEN** a user submits a request with no `specRef` field
+- **THEN** the body sent to GitHub SHALL equal the user's body (with any applicable
+  attribution prefix) and no `---\nRelated capability:` suffix
+- **AND** no `specRef:*` label SHALL be applied
+
+### Requirement: Submission rate limit
+
+The `POST /api/github/issues` endpoint SHALL enforce a per-user rate limit of one
+submission per 60 seconds, stored in APCu under the key
+`openregister.feature_submission:<user_id>`. When a user exceeds the limit, the endpoint
+SHALL return HTTP 429 with body `{"error": "rate_limited", "retry_after": <seconds>}` where
+`retry_after` is the remaining APCu TTL in whole seconds. No outbound GitHub request SHALL
+be issued while the user is rate-limited.
+
+#### Scenario: Second submission within 60 seconds
+
+- **WHEN** a user submits successfully at T=0
+- **AND** the same user submits again at T=10s
+- **THEN** the second response SHALL be HTTP 429
+- **AND** the body SHALL contain `error: "rate_limited"` and a positive integer
+  `retry_after` not greater than 60
+
+### Requirement: Authentication required for submission
+
+The `POST /api/github/issues` endpoint SHALL reject unauthenticated callers with HTTP 401.
+The endpoint MUST NOT carry `#[PublicPage]`; it MUST carry `#[NoAdminRequired]` so that any
+logged-in user can submit.
+
+#### Scenario: Unauthenticated submission
+
+- **WHEN** an anonymous request POSTs `/api/github/issues`
+- **THEN** Nextcloud's middleware SHALL return HTTP 401 before the controller runs
+
+### Requirement: Successful submission response
+
+On success, the controller SHALL return HTTP 201 with a JSON body containing
+`{"number": <int>, "html_url": <string>, "state": <string>}` taken from GitHub's response.
+When the original request included a `specRef`, the response body SHALL additionally
+include `"specRef": <value>`.
+
+#### Scenario: Success payload shape
+
+- **WHEN** a submission succeeds and GitHub returns issue `{number: 42, html_url: "https://github.com/.../issues/42", state: "open"}`
+- **AND** the original request carried `specRef: "catalog-management"`
+- **THEN** the controller SHALL respond HTTP 201 with
+  `{"number": 42, "html_url": "https://github.com/.../issues/42", "state": "open", "specRef": "catalog-management"}`
+
+### Requirement: Parameter validation for list endpoint
+
+The list endpoint SHALL validate the `repo` parameter against the regex
+`^[A-Za-z0-9][A-Za-z0-9_.-]*/[A-Za-z0-9][A-Za-z0-9_.-]*$` and SHALL reject `per_page`
+values outside `[1, 100]`. Invalid values SHALL yield HTTP 400 with a structured error code
+and SHALL NOT be forwarded to GitHub.
+
+#### Scenario: Invalid repo format
+
+- **WHEN** a user requests `GET /api/github/issues?repo=not-a-slug`
+- **THEN** the endpoint SHALL return HTTP 400 with error code `repo_invalid_format`
+- **AND** no request SHALL be made to GitHub
+
+#### Scenario: per_page out of range
+
+- **WHEN** a user requests `GET /api/github/issues?repo=ConductionNL/openregister&per_page=500`
+- **THEN** the endpoint SHALL return HTTP 400 with error code `per_page_out_of_range`
+
+### Requirement: Delegation to GitHubHandler
+
+The controller SHALL delegate all outbound HTTP calls to
+`OCA\OpenRegister\Service\Configuration\GitHubHandler::listIssues(...)` (for GET) and
+`GitHubHandler::createIssue(...)` (for POST). Both handler methods are added as part of
+this change and SHALL reuse the handler's existing Guzzle client, base URL, user-agent, and
+rate-limit error translation. The controller SHALL NOT instantiate any HTTP client
+directly.
+
+#### Scenario: Controller uses the handler
+
+- **WHEN** the controller receives a valid GET request
+- **THEN** it SHALL call `GitHubHandler::listIssues` with the parsed arguments
+- **AND** it SHALL NOT instantiate a separate HTTP client
+
+### Requirement: App-level PAT usage for reads
+
+`GitHubHandler::listIssues` SHALL read the Personal Access Token from `IAppConfig` key
+`openregister::github_api_token`. When the token is present it SHALL be sent as an
+`Authorization: Bearer <token>` header on the GitHub request. The token value SHALL NEVER
+appear in any response body, any response header returned to the client, any log
+statement, any exception message, or any cached payload.
+
+#### Scenario: PAT present for read
+
+- **WHEN** `openregister::github_api_token` is set
+- **AND** an authenticated user requests open issues for a public repo
+- **THEN** the outbound GitHub request SHALL carry the `Authorization: Bearer <TOKEN>` header
+- **AND** the response returned to the client SHALL NOT contain the PAT value in any field
+
+### Requirement: Graceful missing-PAT degradation for reads
+
+When no app-level PAT is configured, the list endpoint SHALL return HTTP 200 with
+`{"items": [], "hint": "github_pat_not_configured"}`. It SHALL NOT return HTTP 401, 403, or
+500 for this condition, and SHALL NOT make an unauthenticated request to GitHub.
+
+#### Scenario: No PAT configured for read
+
+- **WHEN** `openregister::github_api_token` is empty or unset
+- **AND** an authenticated user requests `GET /api/github/issues?repo=ConductionNL/openregister`
+- **THEN** the endpoint SHALL return HTTP 200
+- **AND** the response body SHALL be `{"items": [], "hint": "github_pat_not_configured"}`
+- **AND** no outbound HTTP call SHALL be made to api.github.com
+
+### Requirement: In-memory response cache for reads
+
+GET responses SHALL be cached in-process with a 15-minute TTL keyed by the tuple
+`(repo, state, sort, per_page)`. Cache hits SHALL NOT issue an outbound GitHub request and
+SHALL include a response header `X-OpenRegister-GitHub-Cache: HIT` for observability. Cache
+misses SHALL set the same header to `MISS`. The cache SHALL be instance-global (shared
+across users) and not partitioned per user. The cache SHALL NOT apply to the POST endpoint.
+
+#### Scenario: Second identical request is served from cache
+
+- **WHEN** two identical GET requests for the same `(repo, state, sort, per_page)` arrive
+  within 15 minutes
+- **THEN** the second request SHALL be answered from cache
+- **AND** the response SHALL include `X-OpenRegister-GitHub-Cache: HIT`
+- **AND** only one outbound GitHub request SHALL have been made
+
+#### Scenario: Cache expires after 15 minutes
+
+- **WHEN** a cached response is older than 15 minutes and a new request arrives
+- **THEN** the endpoint SHALL refetch from GitHub
+- **AND** the response SHALL include `X-OpenRegister-GitHub-Cache: MISS`
+
+### Requirement: Rate-limit handling for reads
+
+The list endpoint SHALL translate GitHub rate-limit responses into a structured 429 for the
+client. When GitHub responds with HTTP 403 carrying the `X-RateLimit-Remaining: 0` header,
+or with HTTP 429, the endpoint SHALL return HTTP 429 to the client with a structured body
+of the form `{"error": "github_rate_limited", "reset_at": "<ISO-8601 timestamp>"}`. It
+SHALL derive `reset_at` from GitHub's `X-RateLimit-Reset` header. The endpoint SHALL NOT
+retry automatically within the same request.
+
+#### Scenario: GitHub rate-limits the proxy
+
+- **WHEN** GitHub returns 403 with `X-RateLimit-Remaining: 0`
+- **THEN** the proxy SHALL return HTTP 429 to the client
+- **AND** the body SHALL contain `error: github_rate_limited` and a `reset_at` ISO-8601
+  timestamp derived from `X-RateLimit-Reset`
+
+### Requirement: PAT never leaks
+
+Both the user-level and app-level PAT values SHALL NOT appear in any OpenRegister log file
+(app.log, nextcloud.log, exception traces), any response body or header returned to the
+client, any cached value in the response cache, or any error thrown from the handler. A
+PHPUnit test SHALL assert this by checking the full response payload and log buffer for
+the placeholder token string `YOUR_API_KEY_HERE` after exercising success, error, and
+rate-limit paths with that placeholder in place of a real token.
+
+#### Scenario: PAT leakage check in tests
+
+- **WHEN** the PHPUnit test suite runs the success path, the rate-limit path, and an error
+  path using placeholder token `YOUR_API_KEY_HERE`
+- **THEN** the placeholder value SHALL NOT appear in any intercepted log line
+- **AND** the placeholder value SHALL NOT appear in any response body or response header
+
+### Requirement: Authentication and authorization
+
+Both endpoints SHALL require an authenticated Nextcloud user (no `#[PublicPage]`). They
+SHALL carry `#[NoAdminRequired]` so any logged-in user can read the roadmap and submit
+feature requests. `GET /api/github/issues` SHALL carry `#[NoCSRFRequired]` (pure read).
+`POST /api/github/issues` SHALL NOT carry `#[NoCSRFRequired]` so Nextcloud's CSRF middleware
+protects submissions.
+
+#### Scenario: Unauthenticated read
+
+- **WHEN** an anonymous request hits `GET /api/github/issues?repo=ConductionNL/openregister`
+- **THEN** Nextcloud's middleware SHALL return HTTP 401 before the controller runs
+
+### Requirement: OpenAPI documentation
+
+Both endpoints SHALL be documented in OpenRegister's OpenAPI specification, including the
+GET query parameters, the POST request-body schema, the response schemas (items + hint +
+cache header on GET; created issue shape on POST), and the documented error cases
+(400/401/403/412/429/503). The schema SHALL include an example POST payload using the
+placeholder token `YOUR_API_KEY_HERE` where a PAT would appear in any auth-flow example
+and the nil UUID `00000000-0000-0000-0000-000000000000` where an ID placeholder is needed.
+
+#### Scenario: OpenAPI describes both endpoints
+
+- **WHEN** the OpenAPI spec is regenerated
+- **THEN** it SHALL include `/api/github/issues` with both GET and POST operations and
+  their documented response statuses
diff --git a/openspec/changes/add-features-roadmap-menu/tasks.md b/openspec/changes/add-features-roadmap-menu/tasks.md
new file mode 100644
index 0000000000..fa25b2bb34
--- /dev/null
+++ b/openspec/changes/add-features-roadmap-menu/tasks.md
@@ -0,0 +1,86 @@
+# Tasks: add-features-roadmap-menu
+
+## 1. Backend — OpenRegister (extends existing GitHubHandler)
+
+- [ ] 1.1 Add `listIssues(string $owner, string $repo, string $state = 'open', string $sort = 'reactions-+1', int $perPage = 30): array` method to `lib/Service/Configuration/GitHubHandler.php`, reusing the existing Guzzle client, user-agent, and rate-limit error handling.
+- [ ] 1.2 Add `createIssue(string $owner, string $repo, string $title, string $body, ?string $specRef, string $userId): array` method to `GitHubHandler` with user-PAT preferred (IConfig `openregister::github_token`) and server-PAT fallback (IAppConfig `openregister::github_api_token`). When falling back, prepend the attribution prefix `> Submitted by **<display_name>** via <instance_url>\n\n---\n\n` to the body sent to GitHub.
+- [ ] 1.3 Create `lib/Controller/GitHubIssuesController.php` with:
+  - `index()` action mapped to `GET /api/github/issues` — proxies to `listIssues()`.
+  - `create()` action mapped to `POST /api/github/issues` — validates title (3-200 chars), body (>=10 chars), repo regex `^[\w.-]+/[\w.-]+$`, applies rate limit, delegates to `createIssue()`.
+- [ ] 1.4 Register both routes in `appinfo/routes.php`. Apply attribute declarations per ADR-005: GET carries `#[NoAdminRequired]` + `#[NoCSRFRequired]`; POST carries `#[NoAdminRequired]` but NOT `#[NoCSRFRequired]` (CSRF MUST apply).
+- [ ] 1.5 Implement in-memory TTL cache (15 min) keyed by `(repo, state, sort, per_page)` for GET only; set `X-OpenRegister-GitHub-Cache: HIT|MISS` response header.
+- [ ] 1.6 Implement APCu-backed per-user rate limit for POST — key `openregister.feature_submission:<user_id>`, 60s TTL; return HTTP 429 with `{error: "rate_limited", retry_after: <seconds>}` when exceeded.
+- [ ] 1.7 Graceful degradation: GET returns HTTP 200 `{items: [], hint: "github_pat_not_configured"}` when no app-level PAT set; POST returns HTTP 503 `{error: "github_pat_not_configured"}` when neither user nor app-level PAT is configured.
+- [ ] 1.8 specRef handling in `create()`: when provided, append `\n\n---\nRelated capability: `<specRef>`\n` to body AND apply `specRef:<slug>` label on the created issue.
+- [ ] 1.9 Map GitHub rate-limit (403 with `X-RateLimit-Remaining: 0`, or 429) to HTTP 429 with `{error: "github_rate_limited", reset_at: "<ISO-8601>"}` derived from `X-RateLimit-Reset`.
+- [ ] 1.10 Strip sensitive fields from issue payloads before returning (keep: `number`, `title`, `body`, `html_url`, `user.login`, `user.avatar_url`, `reactions.total_count`, `reactions.+1`, `created_at`, `updated_at`, `labels[].{name,color}`); drop everything else.
+- [ ] 1.11 Add PHPUnit tests for the controller and both handler methods covering: GET success, GET graceful-degraded, GET cache HIT, GET rate-limit mapping, GET invalid repo/per_page rejection, POST success with user PAT (no prefix), POST success with server PAT (with prefix), POST with specRef (body suffix + label), POST rate limit 429, POST missing-both-PATs 503, POST validation errors (title/body/repo), and PAT-leak assertion — the placeholder `YOUR_API_KEY_HERE` must not appear in any response body, header, log, or cache entry.
+- [ ] 1.12 Update `docs/openapi.json` (or equivalent) with both endpoints, their request/response schemas, and all documented error statuses; use `YOUR_API_KEY_HERE` and nil UUID `00000000-0000-0000-0000-000000000000` in examples.
+- [ ] 1.13 Run `composer check:strict` (PHPCS, PHPMD, Psalm, PHPStan) and fix any findings in the new files AND any pre-existing issues encountered.
+
+## 2. Shared library — @conduction/nextcloud-vue
+
+- [ ] 2.1 Create `CnFeaturesAndRoadmapLink.vue` — an `NcAppNavigationItem` that navigates to `/features-roadmap` (route name is a prop so apps can customize).
+- [ ] 2.2 Create route-level view `FeaturesAndRoadmapView.vue` with tabs (Features, Roadmap) and a header "Suggest feature" button that opens `SuggestFeatureModal`.
+- [ ] 2.3 Sub-component `FeaturesTab.vue` — alphabetical list by title, feature docsUrl links open with `target="_blank" rel="noopener noreferrer"`, empty-state message when features array is empty.
+- [ ] 2.4 Sub-component `RoadmapTab.vue` — reaction-sorted list; fetches from `/index.php/apps/openregister/api/github/issues`; renders each via `RoadmapItem`; handles empty/rate-limited/PAT-not-configured states with localized messages.
+- [ ] 2.5 Sub-component `RoadmapItem.vue` — renders one issue: title, submitter login + avatar, reaction count, relative created time, body rendered via `marked` + `DOMPurify` (strict config), filtered label chips using the blocklist constant.
+- [ ] 2.6 Sub-component `SuggestFeatureModal.vue` — title field (3-200 chars, required), body markdown textarea (>=10 chars, required), live preview toggle reusing the same `marked` + `DOMPurify` pipeline, hidden `specRef` field, Submit + Cancel buttons. On Submit, POSTs to `/api/github/issues` with the Nextcloud CSRF token.
+- [ ] 2.7 Composable `useSpecRef()` — reads `specRef` from (a) the nearest ancestor component's `$options.specRef` (Options API) or `defineOptions({ specRef })` (Composition API), with (b) Vue Router `route.meta.specRef` as fallback. Export as part of the package's public API.
+- [ ] 2.8 Mixin / helper `useSuggestFeatureAction()` that returns an `NcActions` item ("Suggest feature") when a non-empty `specRef` is present; opt-in by importing and calling from a widget's NcActions.
+- [ ] 2.9 Export a strict `DOMPurify` configuration constant (`SAFE_MARKDOWN_DOMPURIFY_CONFIG`) from the package so consumers of user-generated markdown reuse one allowlist. Disallow `<script>`, all `on*` attributes, `javascript:` URLs, `<iframe>`, and `<style>`.
+- [ ] 2.10 Export a named constant `ROADMAP_LABEL_BLOCKLIST: RegExp[]` containing the 20 blocklist patterns from D16; document it in the package README.
+- [ ] 2.11 i18n files `l10n/nl.json` + `l10n/en.json` for: route title, tab labels, empty states (all three roadmap degraded conditions), toast messages (success, rate-limit, PAT-not-configured, generic error), modal labels (title, body, preview, submit, cancel), validation error messages.
+- [ ] 2.12 `marked` and `dompurify` wired as peer dependencies in `package.json`.
+- [ ] 2.13 Storybook stories for each component, including three `RoadmapTab` fixtures: happy-path, empty + PAT-not-configured, and rate-limited.
+- [ ] 2.14 Vue unit tests (Jest + @vue/test-utils) covering: `useSpecRef` with component option, `useSpecRef` with route meta fallback, alphabetical feature sort, reaction-sort of roadmap items, label blocklist filtering, XSS vectors stripped by DOMPurify, modal validation (title length, body length), modal submit POST body shape, modal success-toast link, modal rate-limit error rendering.
+- [ ] 2.15 Export everything from `src/index.js`; update package README with usage example for widgets opting into `specRef` and for apps mounting the navigation link + route.
+- [ ] 2.16 Bump minor version + CHANGELOG entry.
+- [ ] 2.17 Run `npm run lint` and `npm test`; fix any findings including pre-existing issues in touched files.
+
+## 3. Build tooling — @conduction/openspec-manifest (CLI only)
+
+- [ ] 3.1 Scaffold new npm package `@conduction/openspec-manifest` with `package.json`, README, license aligned with Conduction house style. Bin entry `openspec-manifest` with subcommand `build`.
+- [ ] 3.2 Implement spec discovery (`lib/discovery.js`): prefer `./openspec/specs/*/spec.md`; fall back to `./specs/*/spec.md` when `./openspec/` is absent; emit stderr warning identifying both paths when both are present; exit 0 with empty manifest when neither exists.
+- [ ] 3.3 Implement frontmatter parser (`lib/parser.js`) using `gray-matter`; skip specs without frontmatter or missing `status:` key with a console warning.
+- [ ] 3.4 Implement status filter: include only `status ∈ {implemented, reviewed}`; skip others without warning (they are expected to be excluded).
+- [ ] 3.5 Implement extractor: first H1 after frontmatter → `title`; enclosing directory name → `slug`; first paragraph under the first `## Purpose` section → `summary`; skip with warning if either title or purpose is missing.
+- [ ] 3.6 Implement docsUrl resolver: if frontmatter `docsUrl:` is set, use verbatim; else resolve git remote (`origin`) + default branch via `git symbolic-ref refs/remotes/origin/HEAD` (NOT the currently checked-out branch) and build `https://github.com/<owner>/<repo>/blob/<defaultBranch>/openspec/specs/<slug>/spec.md`. Omit + warn when remote is not GitHub or when default branch cannot be resolved.
+- [ ] 3.7 Implement writer (`lib/writer.js`): sort entries alphabetically by title (locale-aware, case-insensitive), emit `docs/features.json` (NOT `src/features.json`) as pretty-printed JSON with shape `{schemaVersion: 1, generatedAt: "<ISO>", features: [...]}` and two-space indent.
+- [ ] 3.8 Implement output-schema validation — fail the build with a non-zero exit code and a clear error message when the emitted object does not satisfy the shape.
+- [ ] 3.9 Implement `bin/openspec-manifest.js` CLI with `build` subcommand; honor `--cwd` flag for testability.
+- [ ] 3.10 Jest tests with synthetic spec fixtures: well-formed spec, missing frontmatter, missing `## Purpose`, wrong status, docsUrl frontmatter override, missing git remote, legacy `./specs/` layout, both directories present (warning emitted), slug derivation from directory, determinism (two runs byte-identical except for `generatedAt`), output schema validation fails on malformed shape.
+- [ ] 3.11 Package README: explain `prebuild` integration, the `docs/features.json` location (committed!), and how it is consumed by both the app bundle and `@conduction/docusaurus-features`.
+- [ ] 3.12 Publish package and wire into CI.
+
+## 4. Docusaurus package — @conduction/docusaurus-features (new)
+
+- [ ] 4.1 Scaffold new npm package `@conduction/docusaurus-features` with React and Docusaurus peer deps; set up TypeScript build.
+- [ ] 4.2 Implement `<FeaturesPage />` React component that loads `docs/features.json` at Docusaurus build time (via a Docusaurus plugin hook or `useGlobalData`).
+- [ ] 4.3 Render features in alphabetical order by title, matching the in-app component; render `summary` as plain text (no markdown) and `docsUrl` as an anchor with `target="_blank" rel="noopener noreferrer"`.
+- [ ] 4.4 Visual parity with the in-app component within Docusaurus theming (card layout, capability/status badges, accessible headings).
+- [ ] 4.5 Export a Docusaurus plugin function `createFeaturesPlugin(options)` that registers a `/features` route.
+- [ ] 4.6 Ship nl + en translations using Docusaurus i18n.
+- [ ] 4.7 Jest tests with synthetic manifest fixtures; snapshot tests for rendered output.
+- [ ] 4.8 Package README with a complete `docusaurus.config.js` integration example.
+
+## 5. Pilot integration — OpenRegister itself
+
+- [ ] 5.1 Add `@conduction/openspec-manifest` as a devDependency; wire `"prebuild": "openspec-manifest build"` in `package.json`.
+- [ ] 5.2 Verify `docs/features.json` is regenerated on `npm run build`; confirm it is committed (NOT in `.gitignore`).
+- [ ] 5.3 Add `/features-roadmap` route to the Vue router; mount `FeaturesAndRoadmapView` as its component.
+- [ ] 5.4 Mount `<CnFeaturesAndRoadmapLink />` as the first child of `<NcAppNavigationSettings>` in `src/navigation/MainMenu.vue`, above the existing Settings gear.
+- [ ] 5.5 Bump OpenRegister's dependency on `@conduction/nextcloud-vue` to the version that ships the new component family.
+- [ ] 5.6 Demo: tag 2-3 existing widgets or pages with `specRef` (either `defineOptions({ specRef })` or `meta: { specRef }`) and wire the `useSuggestFeatureAction()` helper into their `NcActions` to validate the end-to-end contract.
+- [ ] 5.7 Install `@conduction/docusaurus-features` in OpenRegister's Docusaurus site; add the plugin and confirm the `/features` page renders.
+- [ ] 5.8 Add a Playwright smoke test: boot OpenRegister, open the navigation sidebar, assert the Features & Roadmap row is visible above the Settings row, click it, assert both tabs render, open the Suggest modal, fill in a valid title + body, submit, assert success toast with issue link.
+- [ ] 5.9 Take before/after screenshot pair of the navigation sidebar + the new route for the PR description.
+
+## 6. Documentation + rollout prep
+
+- [ ] 6.1 README update in OpenRegister explaining the Features & Roadmap feature: admin section (how to configure the server PAT and when user PATs are used), developer section (how to declare `specRef` on a widget/page, how to mount the link + route in a new app).
+- [ ] 6.2 Migration guide under OpenRegister's `docs/` for other Conduction apps to adopt (separate PRs, not this change): add devDep, add prebuild script, bump nextcloud-vue dep, register route, mount nav link, install Docusaurus plugin, common gotchas (private repos, missing PAT, specs with status=proposed, orphan specRef).
+- [ ] 6.3 Placeholder stub in `hydra/openspec/` (or note in the proposal) that ADR-019 will mandate adoption by every Conduction app — explicitly marking this change as the PILOT, not the rollout.
+- [ ] 6.4 Document the label blocklist in the `@conduction/nextcloud-vue` README — the named constant, the 20 patterns, and instructions for extending it.
+- [ ] 6.5 If `docs/adr-008-spec-annotations.md` exists in OpenRegister (or should be created), record that `specRef` (Vue `defineOptions` / route `meta`) is the runtime frontend equivalent of the static `@spec` PHPDoc annotation convention, and that both SHALL use the same kebab-case capability slug.
+- [ ] 6.6 Announce the new component family + endpoint in the internal `#conduction-frontend` channel once the library minor is released.

From 3ad6c642397372c206d628f8fe28a3f06df63ce8 Mon Sep 17 00:00:00 2001
From: Ruben van der Linde <rubenvdlinde@gmail.com>
Date: Wed, 22 Apr 2026 14:41:58 +0200
Subject: [PATCH 2/3] chore(openspec): Add hydra.json linking change to
 tracking issue #1328

Hydra's orchestrator requires a hydra.json per change to dispatch. Adds
the schema-v2 file pointing at issue #1328 with empty depends_on (greenfield
change with no spec dependencies).

Without this file, Hydra's supervisor silently skips the change even if
it carries the `ready-to-build` label.
---
 openspec/changes/add-features-roadmap-menu/hydra.json | 10 ++++++++++
 1 file changed, 10 insertions(+)
 create mode 100644 openspec/changes/add-features-roadmap-menu/hydra.json

diff --git a/openspec/changes/add-features-roadmap-menu/hydra.json b/openspec/changes/add-features-roadmap-menu/hydra.json
new file mode 100644
index 0000000000..26ad4e388c
--- /dev/null
+++ b/openspec/changes/add-features-roadmap-menu/hydra.json
@@ -0,0 +1,10 @@
+{
+  "schema_version": 2,
+  "spec_slug": "add-features-roadmap-menu",
+  "app": "openregister",
+  "repo": "https://github.com/ConductionNL/openregister",
+  "depends_on": [],
+  "issue": "https://github.com/ConductionNL/openregister/issues/1328",
+  "pipeline": {},
+  "cycles": []
+}

From 8e52542e67b0980a63e8a64875f0c75fdbceacb5 Mon Sep 17 00:00:00 2001
From: WilcoLouwerse <wilco@louwerse.com>
Date: Fri, 8 May 2026 11:00:53 +0200
Subject: [PATCH 3/3] spec(pr-1306): address strict-mode review (8 blockers, 7
 concerns, 2 minors)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Addresses every finding from the 2026-05-07 strict-mode review on PR #1306,
all on spec markdown documents (PR is spec-only).

specs/github-issue-proxy/spec.md — added 9 new requirements:
- Required PAT scopes (B1/F-PAT-scope) — minimum public_repo, fine-grained
  preferred, least-privilege documentation MUST
- Token lifecycle (B2) — 90-day rotation cadence, fine-grained preferred,
  documented compromise procedure, optional health-check
- Repo allowlist enforcement (B3+B4) — new IAppConfig key
  openregister::github_repo, both endpoints reject cross-repo with 403
  repo_not_allowed; unset key returns 503 / hint envelope
- Display-name sanitization in attribution prefix (B5) — strip
  markdown-injection chars, truncate to 80, validate https:// instance URL
- specRef server-side validation (B6) — kebab-case regex + 80-char cap,
  HTTP 400 specref_invalid_format
- Audit logging for server-PAT submissions (B7) — INFO entry with
  {user_id, repo, issue_number, specref, timestamp}; never PAT/body/title
- APCu fallback for submission rate limit (C2) — falls back to ICache;
  fails closed with 503 rate_limiter_unavailable when neither is available
- Per-user GET rate limit (C3) — 10 cache misses per user per 5 min,
  sort allowlisted to 4 fixed values

specs/features-roadmap-menu/spec.md — added 4 new requirements:
- DOMPurify config policy on remote images (C1) — strip http(s)://, //,
  data: src on <img>/<image>/<picture>; only relative refs render
- Manifest freshness CI check (C4) — git diff --exit-code on
  docs/features.json after openspec-manifest build
- Admin opt-out for the navigation entry (C5) — new IAppConfig key
  openregister::features_roadmap_enabled, defaults true
- docsUrl frontmatter override validation (M2) — Node URL parse, https:
  scheme only, non-empty hostname; bad override falls back to default

design.md — D14 now documents the specRef body-suffix backtick-wrapping
format (M1), confirming consistency across spec.md / tasks.md / design.md
and noting display-name sanitization references.

hydra.json — issue field changed from URL string to integer per
schema_version 2 (B8) so scripts/lib/hydra_record.py validation passes.

tasks.md — added 17 implementation/follow-up tasks (1.14-1.22 backend
security/resilience/compliance, 2.18-2.20 shared-lib hardening,
3.13-3.14 manifest CLI validation + CI snippet, 5.10-5.11 pilot
integration of opt-out + manifest CI, 6.7 cross-repo openspec validate
strict CI step).

`openspec validate add-features-roadmap-menu --strict` passes (54 deltas
across two specs).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---
 .../add-features-roadmap-menu/design.md       |   9 +-
 .../add-features-roadmap-menu/hydra.json      |   2 +-
 .../specs/features-roadmap-menu/spec.md       | 125 ++++++++++
 .../specs/github-issue-proxy/spec.md          | 235 ++++++++++++++++++
 .../add-features-roadmap-menu/tasks.md        |  17 ++
 5 files changed, 386 insertions(+), 2 deletions(-)

diff --git a/openspec/changes/add-features-roadmap-menu/design.md b/openspec/changes/add-features-roadmap-menu/design.md
index bff57a43d5..267d730a8d 100644
--- a/openspec/changes/add-features-roadmap-menu/design.md
+++ b/openspec/changes/add-features-roadmap-menu/design.md
@@ -177,7 +177,14 @@ The read endpoint returns `200 { items: [], hint: "github_pat_not_configured" }`
   `openregister::github_api_token` (IAppConfig) when the user has no token; on fallback,
   prefix the issue body with
   `> Submitted by **<nc_user_display_name>** via <nc_instance_url>\n\n---\n\n` so
-  traceability survives.
+  traceability survives. Display name and instance URL are sanitized before embedding
+  (see github-issue-proxy spec, "Display-name sanitization in attribution prefix")
+  to prevent markdown-injection or block-termination via the user-controlled display
+  name. When `specRef` is provided, the body sent to GitHub is additionally suffixed
+  with `\n\n---\nRelated capability: \`<specRef>\`\n` (the slug is wrapped in single
+  backticks so GitHub renders it as inline code) AND the created issue carries a
+  `specRef:<slug>` label. The backtick wrapper is intentional and consistent across
+  spec.md / tasks.md / this design.
 
 ### D15. Markdown rendering: `marked` + `DOMPurify`
 
diff --git a/openspec/changes/add-features-roadmap-menu/hydra.json b/openspec/changes/add-features-roadmap-menu/hydra.json
index 26ad4e388c..222039dec2 100644
--- a/openspec/changes/add-features-roadmap-menu/hydra.json
+++ b/openspec/changes/add-features-roadmap-menu/hydra.json
@@ -4,7 +4,7 @@
   "app": "openregister",
   "repo": "https://github.com/ConductionNL/openregister",
   "depends_on": [],
-  "issue": "https://github.com/ConductionNL/openregister/issues/1328",
+  "issue": 1328,
   "pipeline": {},
   "cycles": []
 }
diff --git a/openspec/changes/add-features-roadmap-menu/specs/features-roadmap-menu/spec.md b/openspec/changes/add-features-roadmap-menu/specs/features-roadmap-menu/spec.md
index f24d6be6bb..47577868ec 100644
--- a/openspec/changes/add-features-roadmap-menu/specs/features-roadmap-menu/spec.md
+++ b/openspec/changes/add-features-roadmap-menu/specs/features-roadmap-menu/spec.md
@@ -426,3 +426,128 @@ manifest before the application build runs.
   `"prebuild": "openspec-manifest build"`
 - **THEN** `docs/features.json` SHALL be regenerated before webpack / vite runs
 - **AND** the bundled JS SHALL contain the current manifest contents
+
+### Requirement: DOMPurify config policy on remote images
+
+The `SAFE_MARKDOWN_DOMPURIFY_CONFIG` allowlist SHALL strip all `<img>` tags whose `src`
+attribute resolves to a non-relative external origin (i.e. begins with `http://`,
+`https://`, `//`, or any non-`/` protocol-bearing prefix). Inline `data:` image URLs
+SHALL also be stripped. Only `<img>` elements with relative `src` attributes (e.g.
+`./foo.png`, `/images/bar.svg`) SHALL render — these have no provenance leakage to
+external origins. This is stricter than DOMPurify's default and is required to prevent
+issue authors from embedding tracking-pixel images that leak the viewer's IP, request
+headers, and timing to attacker-controlled origins on every roadmap render.
+
+The same policy SHALL apply to `<image>` (SVG) and `<picture>`/`<source>` elements.
+
+The `SuggestFeatureModal` live-preview pane SHALL use the same configuration so the
+preview matches what will eventually render on the roadmap.
+
+#### Scenario: External image is stripped
+
+- **WHEN** a roadmap issue body contains
+  `<img src="https://tracker.example/pixel.gif">`
+- **THEN** the rendered DOM SHALL NOT contain the `<img>` element
+
+#### Scenario: data: URL image is stripped
+
+- **WHEN** a roadmap issue body contains
+  `<img src="data:image/png;base64,iVBORw0KGgo...">`
+- **THEN** the rendered DOM SHALL NOT contain the `<img>` element
+
+#### Scenario: Relative image is permitted
+
+- **WHEN** a roadmap issue body contains `<img src="./assets/diagram.png">` (rare in
+  GitHub issue bodies but theoretically valid)
+- **THEN** the rendered DOM SHALL contain the `<img>` element verbatim
+
+### Requirement: Manifest freshness CI check
+
+Every host app adopting this capability SHALL include a CI step in its workflow that runs
+`npx openspec-manifest build` and asserts that the resulting `docs/features.json` is
+byte-identical to the committed file (excluding the deterministically-skipped
+`generatedAt` field). The recommended implementation is:
+
+```sh
+npx openspec-manifest build
+git diff --exit-code -- docs/features.json
+```
+
+The CI step SHALL fail the build when `docs/features.json` is out of sync with the
+underlying `openspec/specs/*/spec.md` content. The migration guide SHALL document this
+step as a MUST-have for adopting apps. The shared `@conduction/openspec-manifest` package
+SHALL document the recommended GitHub Actions snippet in its README.
+
+#### Scenario: Stale manifest is caught
+
+- **WHEN** a developer modifies a spec's frontmatter to flip `status: proposed` →
+  `status: implemented` AND commits without re-running the prebuild AND opens a PR
+- **THEN** the CI step `git diff --exit-code -- docs/features.json` SHALL exit non-zero
+- **AND** the workflow SHALL fail with a clear message instructing the developer to run
+  `npx openspec-manifest build` and re-commit
+
+### Requirement: Admin opt-out for the navigation entry
+
+The host app SHALL gate the rendering of `<CnFeaturesAndRoadmapLink>` on the boolean
+IAppConfig key `openregister::features_roadmap_enabled`, defaulting to `true` when the
+key is absent. When the key is `false`, neither the navigation entry nor the
+`/features-roadmap` route SHALL be reachable: the link SHALL be hidden and a direct
+navigation to the route SHALL render a localized "This feature has been disabled by your
+administrator" message instead of the tabs.
+
+The `SuggestFeatureModal`'s widget-level entry points (action menu items injected into
+widgets that declared `specRef`) SHALL also respect this flag — when `false`, the action
+menu item SHALL be hidden. The corresponding backend endpoints (`GET` and `POST` on
+`/api/github/issues`) SHALL also check the flag and return HTTP 403 with the structured
+error code `feature_disabled` when invoked while the flag is `false`, so a user who
+crafted a direct request cannot bypass the UI gate.
+
+This addresses operator personas (e.g. municipal/government deployments under CISO
+control) that may need to disable external-data-egress feature-request submissions for
+compliance reasons without forking the codebase.
+
+#### Scenario: Admin disables the feature
+
+- **WHEN** the administrator sets `openregister::features_roadmap_enabled = false`
+- **THEN** the navigation sidebar SHALL NOT render the Features & Roadmap entry
+- **AND** a logged-in user navigating directly to `/features-roadmap` SHALL see the
+  localized "This feature has been disabled by your administrator" message
+- **AND** any direct call to `GET /api/github/issues` or `POST /api/github/issues` SHALL
+  return HTTP 403 with body `{error: "feature_disabled"}`
+
+#### Scenario: Default behavior
+
+- **WHEN** the IAppConfig key `openregister::features_roadmap_enabled` is absent
+- **THEN** the feature SHALL render normally (default `true`)
+
+### Requirement: docsUrl frontmatter override validation
+
+The `@conduction/openspec-manifest` CLI SHALL validate any frontmatter `docsUrl:` override before accepting it as the manifest entry's `docsUrl`. The value MUST:
+
+1. Be a syntactically valid URL parseable by Node's `URL` constructor.
+2. Use the `https:` scheme (case-insensitive). `http:`, `javascript:`, `data:`, `file:`,
+   and any other scheme SHALL be rejected.
+3. Have a non-empty hostname.
+
+When validation fails, the CLI SHALL emit a stderr warning naming the spec file and the
+invalid value, treat the override as absent, and fall back to the default computed
+`docsUrl`. The CLI SHALL NOT abort the build on a single invalid `docsUrl`; one bad spec
+SHALL NOT poison the whole manifest.
+
+#### Scenario: javascript: URL override is rejected
+
+- **WHEN** a spec frontmatter contains `docsUrl: javascript:alert(1)`
+- **THEN** the CLI SHALL emit a stderr warning naming the spec
+- **AND** the manifest entry's `docsUrl` SHALL be the default computed value (or omitted
+  if no default could be resolved)
+
+#### Scenario: http: URL override is rejected
+
+- **WHEN** a spec frontmatter contains `docsUrl: http://example.com/foo`
+- **THEN** the CLI SHALL emit a stderr warning naming the spec
+- **AND** the manifest entry's `docsUrl` SHALL be the default computed value
+
+#### Scenario: Valid https: URL override is accepted
+
+- **WHEN** a spec frontmatter contains `docsUrl: https://docs.example.com/foo`
+- **THEN** the manifest entry's `docsUrl` SHALL be `https://docs.example.com/foo` verbatim
diff --git a/openspec/changes/add-features-roadmap-menu/specs/github-issue-proxy/spec.md b/openspec/changes/add-features-roadmap-menu/specs/github-issue-proxy/spec.md
index 27c5b00bc6..3ffbfcf929 100644
--- a/openspec/changes/add-features-roadmap-menu/specs/github-issue-proxy/spec.md
+++ b/openspec/changes/add-features-roadmap-menu/specs/github-issue-proxy/spec.md
@@ -325,3 +325,238 @@ and the nil UUID `00000000-0000-0000-0000-000000000000` where an ID placeholder
 - **WHEN** the OpenAPI spec is regenerated
 - **THEN** it SHALL include `/api/github/issues` with both GET and POST operations and
   their documented response statuses
+
+### Requirement: Required PAT scopes
+
+The minimum GitHub OAuth scope required for both PATs SHALL be `public_repo` only — no
+broader scope (`repo`, `admin:org`, `delete_repo`, etc.) is required by any code path in
+this capability. The app-level PAT (`openregister::github_api_token`) SHALL be used solely
+for read access to public-repo issues, which `public_repo` covers. The user-level PAT
+(`openregister::github_token`) SHALL be used solely for creating issues on the configured
+public repo, which `public_repo` also covers. Admin documentation MUST instruct operators
+to provision PATs with the least-privilege `public_repo` scope; if a PAT carries broader
+scope the system cannot detect or reject it, but the documentation SHALL warn that doing
+so violates least-privilege and increases blast radius if the PAT leaks.
+
+Fine-grained PATs SHOULD be preferred over classic PATs because they allow scoping to the
+single configured repository in addition to scoping by permission.
+
+#### Scenario: Admin docs surface the required scope
+
+- **WHEN** an administrator reads the OpenRegister admin documentation for configuring the
+  app-level GitHub PAT
+- **THEN** the docs SHALL state that the minimum required scope is `public_repo`
+- **AND** the docs SHALL warn that broader scopes (e.g. `repo`, `admin:org`) violate least
+  privilege and SHOULD NOT be granted
+
+### Requirement: Token lifecycle
+
+The github-issue-proxy capability SHALL define an explicit operational lifecycle for both
+the app-level and user-level PATs, covering rotation, expiry, and compromise response:
+
+1. **Preference for fine-grained PATs.** Documentation SHALL recommend GitHub fine-grained
+   PATs with an explicit expiry over classic PATs (which never expire by default).
+2. **Recommended rotation cadence.** Documentation SHALL state a recommended rotation
+   cadence of 90 days for the app-level PAT. User PATs are rotated by the user themselves;
+   no system-imposed cadence applies.
+3. **Compromise response.** Documentation SHALL state that on suspected compromise the
+   server PAT MUST be revoked at GitHub immediately, replaced in OpenRegister via the
+   admin settings UI, and the audit-log records produced under the audit-logging
+   requirement SHALL be reviewed for unexpected `repo` or volume signals.
+4. **Expiry detection.** The implementation MAY add an admin-facing health-check (e.g. a
+   periodic background job or a settings-page status indicator) that calls
+   `GET /user` with the configured PAT and surfaces a non-200 response (typically 401 on
+   expired tokens) before silent failure across the proxy. When implemented, the health
+   check MUST NOT log the PAT value on failure.
+
+#### Scenario: Admin docs document rotation cadence and revocation procedure
+
+- **WHEN** an administrator reads the OpenRegister admin documentation for the app-level
+  GitHub PAT
+- **THEN** the docs SHALL state a recommended rotation cadence of 90 days
+- **AND** the docs SHALL state the procedure to revoke at GitHub and replace in
+  OpenRegister on suspected compromise
+
+### Requirement: Repo allowlist enforcement
+
+Both endpoints SHALL enforce a server-side allowlist that constrains the `repo` parameter
+to the single repository configured for this OpenRegister instance. The allowlist SHALL be
+sourced from a new IAppConfig key `openregister::github_repo` (format `<owner>/<repo>`)
+configured by the administrator. The controller MUST validate that the request's `repo`
+parameter (GET) or `repo` body field (POST) equals the configured value before any
+delegation to `GitHubHandler`. Requests for any other repository SHALL be rejected with
+HTTP 403 and the structured error code `repo_not_allowed`. No outbound GitHub request
+SHALL be issued for rejected calls.
+
+When `openregister::github_repo` is unset, both endpoints SHALL behave as if no PAT were
+configured (GET → HTTP 200 `{items: [], hint: "github_repo_not_configured"}`; POST → HTTP
+503 `{error: "github_repo_not_configured"}`) and SHALL NOT issue an outbound GitHub
+request. This collapses the user-supplied-`repo` attack surface to a single
+admin-configured value.
+
+#### Scenario: POST to a non-configured repo is rejected
+
+- **WHEN** an authenticated user POSTs `{repo: "torvalds/linux", title: "Spam", body: "spam body 10+ chars"}`
+- **AND** `openregister::github_repo` is set to `ConductionNL/openregister`
+- **THEN** the endpoint SHALL return HTTP 403 with error code `repo_not_allowed`
+- **AND** no outbound GitHub request SHALL be issued
+
+#### Scenario: GET for a non-configured repo is rejected
+
+- **WHEN** an authenticated user requests `GET /api/github/issues?repo=torvalds/linux`
+- **AND** `openregister::github_repo` is set to `ConductionNL/openregister`
+- **THEN** the endpoint SHALL return HTTP 403 with error code `repo_not_allowed`
+- **AND** no outbound GitHub request SHALL be issued
+
+#### Scenario: GitHub repo not configured
+
+- **WHEN** `openregister::github_repo` is empty or unset
+- **AND** an authenticated user POSTs `/api/github/issues` with any `repo` value
+- **THEN** the endpoint SHALL return HTTP 503 with body `{error: "github_repo_not_configured"}`
+- **AND** no outbound GitHub request SHALL be issued
+
+### Requirement: Display-name sanitization in attribution prefix
+
+When the server PAT fallback path is used, the controller SHALL escape the embedded
+`<display_name>` and `<instance_url>` values before building the attribution block to
+prevent markdown-injection or block-termination attacks via the user-controlled display
+name. Sanitization SHALL strip all newline characters (`\r`, `\n`) and the markdown-
+significant characters `*`, `_`, `[`, `]`, `(`, `)`, `` ` ``, `<`, `>`, `\` from the
+display name before embedding. The resulting attribution block SHALL be:
+
+```
+> Submitted by **<sanitized_display_name>** via <sanitized_instance_url>
+
+---
+
+```
+
+The sanitized display name SHALL be truncated to 80 characters maximum to bound the
+attribution-prefix length. The sanitized instance URL SHALL be validated to begin with
+`https://` (or `http://` only on `localhost` for development); other schemes SHALL cause
+the prefix to fall back to a generic literal `> Submitted via Nextcloud OpenRegister`
+without embedding the URL at all.
+
+#### Scenario: Display name with markdown-injection characters
+
+- **WHEN** the user's Nextcloud display name is `** via evil.com\n\n[Forged Admin]`
+- **AND** the server PAT fallback is used
+- **THEN** the attribution prefix SHALL render the display name as
+  `   via evil.com  Forged Admin` (all `*`, `_`, `[`, `]`, `(`, `)`, `` ` ``, `<`, `>`,
+  `\`, and newline characters stripped, replaced with spaces)
+- **AND** the `\n\n---\n\n` separator SHALL appear exactly once and only after the
+  sanitized prefix
+
+#### Scenario: Excessively long display name
+
+- **WHEN** the user's display name is 200 characters long
+- **THEN** the attribution prefix SHALL embed only the first 80 characters of the
+  sanitized name
+
+### Requirement: specRef server-side validation
+
+When the request body includes a `specRef` field, the controller SHALL validate the value
+against the regex `^[a-z0-9][a-z0-9-]*[a-z0-9]$` (kebab-case, identical to the ADR-008
+capability-slug convention) and SHALL reject values longer than 80 characters. Validation
+failures SHALL yield HTTP 400 with the structured error code `specref_invalid_format` and
+SHALL NOT issue an outbound GitHub request. An empty or absent `specRef` field is valid
+and SHALL skip the body suffix and label-application logic per the existing requirement.
+
+#### Scenario: Invalid specRef format
+
+- **WHEN** a user POSTs `{repo: "ConductionNL/openregister", title: "Valid title", body: "Valid body 10+ chars.", specRef: "Bad Slug!"}`
+- **THEN** the endpoint SHALL return HTTP 400 with error code `specref_invalid_format`
+- **AND** no outbound GitHub request SHALL be issued
+
+#### Scenario: specRef with newline injection
+
+- **WHEN** a user POSTs `{... specRef: "slug\nnewline-content"}`
+- **THEN** the endpoint SHALL return HTTP 400 with error code `specref_invalid_format`
+
+#### Scenario: specRef exceeds length cap
+
+- **WHEN** a user POSTs `{... specRef: "<81-character valid slug>"}`
+- **THEN** the endpoint SHALL return HTTP 400 with error code `specref_invalid_format`
+
+### Requirement: Audit logging for server-PAT submissions
+
+When the server-PAT fallback path is used to create an issue, the implementation SHALL
+write a single audit-log entry at INFO level to Nextcloud's `app.log` containing exactly
+the fields:
+
+- `user_id` — the Nextcloud UID of the submitting user.
+- `repo` — the `<owner>/<repo>` value from the validated request.
+- `issue_number` — the integer issue number returned by GitHub.
+- `specref` — the validated `specRef` value, or empty string if absent.
+- `timestamp` — RFC 3339 timestamp from server clock.
+
+The log entry MUST NOT contain the PAT value, the issue body, the issue title, or the
+attribution prefix. Submissions made with the user-PAT path SHALL NOT produce this audit
+entry (those are auditable on GitHub directly under the user's identity). Failed
+submissions (any non-201 response from GitHub) SHALL log a separate WARNING entry
+containing the same fields plus an `error_code` and the GitHub status code, again with no
+PAT value.
+
+#### Scenario: Successful server-PAT submission emits audit entry
+
+- **WHEN** a user submits successfully via the server-PAT fallback path and GitHub returns
+  issue 42 on `ConductionNL/openregister`
+- **THEN** Nextcloud's `app.log` SHALL contain exactly one INFO entry from the
+  `openregister` app with fields `{user_id, repo: "ConductionNL/openregister", issue_number: 42, specref: "", timestamp}`
+- **AND** the entry SHALL NOT contain the PAT value or the issue body
+
+#### Scenario: User-PAT submission does not emit server-side audit entry
+
+- **WHEN** the same user submits using their own PAT (not the fallback)
+- **THEN** no `openregister` audit entry SHALL be emitted (GitHub audit covers it under
+  the user's identity)
+
+### Requirement: APCu fallback for submission rate limit
+
+When APCu is unavailable on the PHP installation, the POST endpoint SHALL fall back to
+Nextcloud's `ICache` (via `ICacheFactory::createDistributed()` or `createLocking()`) to
+enforce the per-user rate limit. The implementation SHALL NOT silently bypass the rate
+limit when APCu is absent. When neither APCu nor any `ICache` backend is available
+(extremely rare in production deployments), the endpoint SHALL fail closed with HTTP 503
+and the structured error code `rate_limiter_unavailable`, and SHALL NOT issue an outbound
+GitHub request.
+
+#### Scenario: APCu unavailable, distributed cache available
+
+- **WHEN** APCu is not loaded on PHP
+- **AND** Nextcloud's distributed cache (e.g. Redis, Memcached) is available
+- **THEN** the rate-limit key `openregister.feature_submission:<user_id>` SHALL be stored
+  in the distributed cache with the same 60s TTL semantics
+- **AND** the second submission within 60s SHALL still receive HTTP 429
+
+#### Scenario: APCu unavailable and no other cache backend
+
+- **WHEN** no rate-limit-capable cache backend is available
+- **THEN** the POST endpoint SHALL fail closed with HTTP 503 and error code `rate_limiter_unavailable`
+- **AND** no outbound GitHub request SHALL be issued
+
+### Requirement: Per-user GET rate limit
+
+The GET endpoint SHALL enforce a per-user rate limit on cache-miss requests of at most 10
+distinct cache-key tuples per user per 5-minute window, to prevent a single user from
+exhausting the app-level PAT's GitHub rate budget by varying `sort` or `per_page` to
+defeat the in-memory cache. Cache hits SHALL NOT count against this limit. The limiter
+SHALL share the same APCu/`ICache` fallback semantics as the POST limiter. When the limit
+is exceeded, the endpoint SHALL return HTTP 429 with the structured body
+`{"error": "user_rate_limited", "retry_after": <seconds>}` and SHALL NOT issue an outbound
+GitHub request. Additionally, the endpoint SHALL constrain the `sort` query parameter to
+the fixed set `{"reactions-+1", "created", "updated", "comments"}` (rejecting other values
+with HTTP 400 `sort_invalid_value`) so the cache-key space is naturally bounded.
+
+#### Scenario: User exhausts cache-miss budget
+
+- **WHEN** a single user makes 11 GET requests within 5 minutes, each varying `per_page`
+  to produce a distinct cache key, all of which miss the cache
+- **THEN** the 11th response SHALL be HTTP 429 with body
+  `{error: "user_rate_limited", retry_after: <positive integer ≤ 300>}`
+- **AND** no outbound GitHub request SHALL be issued for the 11th call
+
+#### Scenario: Invalid sort value
+
+- **WHEN** a user requests `GET /api/github/issues?repo=ConductionNL/openregister&sort=stars`
+- **THEN** the endpoint SHALL return HTTP 400 with error code `sort_invalid_value`
diff --git a/openspec/changes/add-features-roadmap-menu/tasks.md b/openspec/changes/add-features-roadmap-menu/tasks.md
index fa25b2bb34..17f6ada08a 100644
--- a/openspec/changes/add-features-roadmap-menu/tasks.md
+++ b/openspec/changes/add-features-roadmap-menu/tasks.md
@@ -17,6 +17,15 @@
 - [ ] 1.11 Add PHPUnit tests for the controller and both handler methods covering: GET success, GET graceful-degraded, GET cache HIT, GET rate-limit mapping, GET invalid repo/per_page rejection, POST success with user PAT (no prefix), POST success with server PAT (with prefix), POST with specRef (body suffix + label), POST rate limit 429, POST missing-both-PATs 503, POST validation errors (title/body/repo), and PAT-leak assertion — the placeholder `YOUR_API_KEY_HERE` must not appear in any response body, header, log, or cache entry.
 - [ ] 1.12 Update `docs/openapi.json` (or equivalent) with both endpoints, their request/response schemas, and all documented error statuses; use `YOUR_API_KEY_HERE` and nil UUID `00000000-0000-0000-0000-000000000000` in examples.
 - [ ] 1.13 Run `composer check:strict` (PHPCS, PHPMD, Psalm, PHPStan) and fix any findings in the new files AND any pre-existing issues encountered.
+- [ ] 1.14 **Repo allowlist enforcement (security):** read `openregister::github_repo` from IAppConfig at the start of both `index()` and `create()`; reject any request whose `repo` parameter/body field does not equal the configured value with HTTP 403 `repo_not_allowed`; when the key is unset, return HTTP 200 `{items: [], hint: "github_repo_not_configured"}` (GET) or HTTP 503 `{error: "github_repo_not_configured"}` (POST). Add PHPUnit cases: `repo_not_allowed` 403 on cross-repo POST, `repo_not_allowed` 403 on cross-repo GET, `github_repo_not_configured` graceful response on unset config.
+- [ ] 1.15 **Display-name + instance-URL sanitization (security):** in `GitHubHandler::createIssue`'s server-PAT-fallback branch, sanitize the display name (strip `\r`, `\n`, `*`, `_`, `[`, `]`, `(`, `)`, `` ` ``, `<`, `>`, `\` — replace with spaces — then truncate to 80 chars) and validate the instance URL begins with `https://` (or `http://localhost`); on scheme failure, fall back to the literal `> Submitted via Nextcloud OpenRegister` block without embedding the URL. Add PHPUnit cases: markdown-injection display name produces sanitized output, separator `\n\n---\n\n` appears exactly once, oversized display name is truncated to 80 chars, non-https instance URL falls back to generic prefix.
+- [ ] 1.16 **specRef format validation (security):** before delegating to `createIssue`, validate `specRef` matches `^[a-z0-9][a-z0-9-]*[a-z0-9]$` with length ≤ 80 when present; reject with HTTP 400 `specref_invalid_format`. Add PHPUnit cases: invalid characters, embedded newline, length > 80, valid kebab-case slug accepted, empty/absent value accepted.
+- [ ] 1.17 **Audit logging for server-PAT submissions (security):** when `createIssue` falls through to the server PAT path AND the GitHub call succeeds (201), emit ONE INFO entry to `app.log` with exactly the fields `{user_id, repo, issue_number, specref, timestamp}`; on failure, emit a WARNING entry with the same fields plus `{error_code, github_status}`. Never log PAT, body, or title. Add PHPUnit cases: success path emits exactly one INFO entry with no PAT/body/title in the message, failure path emits exactly one WARNING with the error code, user-PAT path emits NO `openregister`-app entry.
+- [ ] 1.18 **APCu-unavailable rate-limit fallback (resilience):** abstract the rate-limiter behind an interface; primary impl uses APCu, fallback impl uses Nextcloud's `ICacheFactory::createDistributed()` / `createLocking()`; when neither is available, fail closed with HTTP 503 `rate_limiter_unavailable`. Apply to BOTH the POST submission limiter AND the new GET cache-miss limiter. Add PHPUnit cases: APCu disabled + distributed cache available → 429 still fires on second submission within 60s; both unavailable → 503 `rate_limiter_unavailable`.
+- [ ] 1.19 **Per-user GET rate limit (resilience):** instrument the GET endpoint with a per-user cache-miss counter (max 10 distinct cache keys per user per 5 min); cache hits do not count; on exceed, respond HTTP 429 `{error: "user_rate_limited", retry_after}`. Add PHPUnit case: 11th distinct cache-miss request from the same user in 5 min returns 429.
+- [ ] 1.20 **`sort` parameter allowlist (resilience):** constrain `sort` to `{"reactions-+1", "created", "updated", "comments"}`; reject other values with HTTP 400 `sort_invalid_value`. Add PHPUnit case: `sort=stars` returns 400 `sort_invalid_value`.
+- [ ] 1.21 **Admin opt-out (compliance):** read `openregister::features_roadmap_enabled` (default `true`) at the start of both `index()` and `create()`; when `false`, return HTTP 403 `{error: "feature_disabled"}` and skip all downstream logic. Add PHPUnit case: flag false → both endpoints return 403.
+- [ ] 1.22 **Admin documentation (PAT scopes + token lifecycle):** in OpenRegister's admin docs section for the GitHub integration, document the minimum required PAT scope (`public_repo`), the recommendation to prefer fine-grained PATs with explicit expiry, the recommended rotation cadence (90 days), and the revocation procedure on suspected compromise. Add a section explaining the `openregister::github_repo` allowlist key and the `openregister::features_roadmap_enabled` opt-out flag.
 
 ## 2. Shared library — @conduction/nextcloud-vue
 
@@ -37,6 +46,9 @@
 - [ ] 2.15 Export everything from `src/index.js`; update package README with usage example for widgets opting into `specRef` and for apps mounting the navigation link + route.
 - [ ] 2.16 Bump minor version + CHANGELOG entry.
 - [ ] 2.17 Run `npm run lint` and `npm test`; fix any findings including pre-existing issues in touched files.
+- [ ] 2.18 **DOMPurify image-policy hardening:** extend `SAFE_MARKDOWN_DOMPURIFY_CONFIG` with a `uponSanitizeAttribute` (or equivalent hook) that strips `src` attributes on `<img>`, `<image>` (SVG), and `<picture>`/`<source>` whose values resolve to `http://`, `https://`, `//`, or `data:` URLs; only relative `src` values pass through. Add Jest cases for: external `https://` image stripped, `data:` image stripped, relative `./foo.png` permitted, SVG `<image href="https://...">` stripped.
+- [ ] 2.19 **Admin opt-out gating:** `CnFeaturesAndRoadmapLink` SHALL read the disabled state from a prop (host app passes the IAppConfig value) and SHALL render nothing when `false`. `FeaturesAndRoadmapView` SHALL render the localized "This feature has been disabled by your administrator" message when `disabled=true`. `useSuggestFeatureAction()` SHALL return null when `disabled=true`. Add Jest cases for each.
+- [ ] 2.20 **specRef format validation in modal:** `SuggestFeatureModal` SHALL validate any pre-filled `specRef` against the same regex as the backend (`^[a-z0-9][a-z0-9-]*[a-z0-9]$`, ≤ 80 chars) before submit; on mismatch, log a console warning and clear the hidden field rather than POSTing a value the backend will reject. Add Jest cases.
 
 ## 3. Build tooling — @conduction/openspec-manifest (CLI only)
 
@@ -52,6 +64,8 @@
 - [ ] 3.10 Jest tests with synthetic spec fixtures: well-formed spec, missing frontmatter, missing `## Purpose`, wrong status, docsUrl frontmatter override, missing git remote, legacy `./specs/` layout, both directories present (warning emitted), slug derivation from directory, determinism (two runs byte-identical except for `generatedAt`), output schema validation fails on malformed shape.
 - [ ] 3.11 Package README: explain `prebuild` integration, the `docs/features.json` location (committed!), and how it is consumed by both the app bundle and `@conduction/docusaurus-features`.
 - [ ] 3.12 Publish package and wire into CI.
+- [ ] 3.13 **docsUrl override URL validation:** in `lib/parser.js` (or a new `lib/docs-url.js`), validate frontmatter `docsUrl:` overrides via Node's `URL` constructor; reject non-`https:` schemes or empty hostnames with a stderr warning naming the spec; fall back to the default computed `docsUrl` on rejection. Add Jest cases: `javascript:`, `data:`, `http:`, malformed URL, valid `https://` accepted.
+- [ ] 3.14 **Manifest freshness CI snippet:** in the package README, include a recommended GitHub Actions snippet that runs `npx openspec-manifest build && git diff --exit-code -- docs/features.json` and fails the build on diff. Document this as a MUST-have step for adopting apps.
 
 ## 4. Docusaurus package — @conduction/docusaurus-features (new)
 
@@ -75,6 +89,8 @@
 - [ ] 5.7 Install `@conduction/docusaurus-features` in OpenRegister's Docusaurus site; add the plugin and confirm the `/features` page renders.
 - [ ] 5.8 Add a Playwright smoke test: boot OpenRegister, open the navigation sidebar, assert the Features & Roadmap row is visible above the Settings row, click it, assert both tabs render, open the Suggest modal, fill in a valid title + body, submit, assert success toast with issue link.
 - [ ] 5.9 Take before/after screenshot pair of the navigation sidebar + the new route for the PR description.
+- [ ] 5.10 **Manifest freshness CI step:** add a GitHub Actions step in OpenRegister's existing workflow that runs `npx openspec-manifest build && git diff --exit-code -- docs/features.json` to catch stale manifests in PRs.
+- [ ] 5.11 **Wire opt-out flag through the bundle:** OpenRegister's `MainMenu.vue` SHALL pass the `openregister::features_roadmap_enabled` IAppConfig value (read once on page load, defaulting to `true`) as a prop into `CnFeaturesAndRoadmapLink`. The Vue route guard for `/features-roadmap` SHALL also check the same value and redirect to a "feature disabled" view when `false`.
 
 ## 6. Documentation + rollout prep
 
@@ -84,3 +100,4 @@
 - [ ] 6.4 Document the label blocklist in the `@conduction/nextcloud-vue` README — the named constant, the 20 patterns, and instructions for extending it.
 - [ ] 6.5 If `docs/adr-008-spec-annotations.md` exists in OpenRegister (or should be created), record that `specRef` (Vue `defineOptions` / route `meta`) is the runtime frontend equivalent of the static `@spec` PHPDoc annotation convention, and that both SHALL use the same kebab-case capability slug.
 - [ ] 6.6 Announce the new component family + endpoint in the internal `#conduction-frontend` channel once the library minor is released.
+- [ ] 6.7 **CI: openspec validate strict on every PR.** Add a GitHub Actions step (or extend an existing workflow) that runs `openspec validate add-features-roadmap-menu --strict` (and equivalent for any other in-flight changes) on every PR touching `openspec/changes/**`. This catches spec-shape regressions automatically rather than relying on manual architecture review for spec-only PRs.