doc-* statt solcom:*Die neue PRD verwendet doc-title, doc-status, doc-owner usw. Das kanonische Schema laut CLAUDE.md ist ausschliesslich solcom:*. Nur solcom:jira-key ist korrekt. Das bricht solcom-docs-lint und solcom-docs-explorer, die auf solcom:*-Namespacing filtern.
Falsch: <meta name="doc-status" content="approved"> — Korrekt: <meta name="solcom:status" content="approved">
ignore_elements schliesst footer und nav ausFooter und Navigation enthalten auf SOLCOM-Seiten realen Content (Links, Kontaktdaten). Die Story begründet nur „Admin-Chrome-Ausschluss" — ob footer/nav bewusst Post-Launch-Tuning sind, fehlt als explizites Non-Goal im PRD.
content_editor unklarDie Views verlangen manage editoria11y results. content_editor erhält diese Permission nicht. Falls das Dashboard auch für Redakteure gedacht ist, fehlt entweder eine weitere Permission oder ein separater Block mit niedrigerer Zugriffshürde.
approved während Story noch in-reviewStatus-Divergenz zwischen den beiden Docs — verwirrend für den Audit-Trail, triggert solcom-docs-lint Regel "status-drift".
PRD-Tabelle verlangt für Administrator: administer editoria11y checker, manage editoria11y results, mark as ok in editoria11y. Im Diff gibt es kein user.role.administrator.yml. is_admin: true gibt impliziten Vollzugriff, aber ohne expliziten Config-Export ist das auf Instanzen mit überschriebenem Admin-Rollen-YAML nicht garantiert.
mark as hidden für Redakteur — nicht in Speccontent_editor bekommt mark as hidden in editoria11y. Die PRD-Tabelle weist Redakteuren ausschliesslich view editoria11y checker zu. Keine "mark"-Permission gehört laut Spec zum Redakteur-Scope.
Jira-Story und PRD verlangen den Block a11y_tools_editoria11y_results-block_a11y_alerts sichtbar im Dashboard. Im Diff gibt es Views-Config, aber kein block.block.*.yml. AK3 ("keine manuelle Nachkonfiguration") ist damit nicht nachweislich erfüllt.
config/sync/Wenn der View 1:1 dem Modul-Default entspricht, erzeugt er bei jedem Modul-Update einen Config-Conflict ohne Mehrwert. Die Spec erwähnt diesen View nicht explizit.
assertiveness: assertive — nicht spezifiziert, potenziell WCAG-kontraproduktivWert assertive löst ARIA-Live-Announcements bei jedem Seitenbesuch aus — kann für Screenreader-Nutzer störend sein. Die PRD-Settings-Tabelle enthält diesen Wert nicht. Da das Ziel WCAG-Konformität ist, sollte er explizit begründet oder auf den Standardwert zurückgesetzt werden.