`pollora:status` reports the auto-derived slug instead of the explicit `#[PostType]` slug

[ogorzalka]

Summary

pollora:status displays a post type slug derived from the class name, ignoring the slug passed to the attribute. The registered post type and the reported one differ.

Reproduction

#[PostType('synthese-presse', singular: 'Synthèse de presse', plural: 'Synthèses de presse')]
#[PublicPostType]
class SyntheseDePresse {}

pollora:status reports:

Post Types: 1 registered (via discovery)
  · Synthese De Presse [synthese-de-presse] — App\Cms\PostTypes\SyntheseDePresse

WordPress actually registered:

$ wp post-type list --field=name | grep synthese
synthese-presse

So the command shows synthese-de-presse (kebab-case of the class name) while the real slug is synthese-presse. The singular/plural labels from the attribute are ignored too — it prints "Synthese De Presse" rather than "Synthèse de presse".

Why it matters

The registration itself is correct; only the reporting is wrong. But pollora:status is the natural place to look up a slug when wiring anything that references a post type by name — a metabox location, a query, a route. Trusting its output silently targets a post type that does not exist, and the failure is quiet: no error, the feature just never appears.

This cost a debugging round trip on a real project: a Meta Box metabox scoped to the slug shown by pollora:status simply never rendered.

Expected

Report the slug and labels actually used at registration — the attribute values when provided, the derived ones only as a fallback.

Environment

Pollora v13.4.3 · WordPress 6.9.4 · PHP 8.4.20 · Laravel 13.8.0

https://claude.ai/code/session_01CtKVtFGujknnYGtcEEJD3x