[xwiki/xwiki-dev-llm] aa6eed: [Misc] Record that e.x.o extension pages keep docu...
Branch: refs/heads/okf-exo-installation-xproperty Home: https://github.com/xwiki/xwiki-dev-llm Commit: aa6eedf9c6119ed5437063ffda06f9c5f70b0c6b https://github.com/xwiki/xwiki-dev-llm/commit/aa6eedf9c6119ed5437063ffda06f9... Author: Vincent Massol <[email protected]> Date: 2026-07-27 (Mon, 27 Jul 2026) Changed paths: M .claude-plugin/marketplace.json M kimi.plugin.json M opencode.jsonc M xwiki/.claude-plugin/plugin.json M xwiki/okf/conventions/documentation.md M xwiki/skills/xwiki-doc-convert/SKILL.md Log Message: ----------- [Misc] Record that e.x.o extension pages keep documentation in several xproperties Converting the JIRA extension pages to the new documentation tree showed that extracting only the ExtensionClass `description` xproperty silently drops content: the CKEditor page's `installation` xproperty held a mandatory activation step that ended up in none of the 20 new pages, and the omission was undetectable afterwards because the "nothing lost" sweeps compared the new pages against the already-incomplete extraction. Add to okf/conventions/documentation.md a table of which xproperty of which xobject holds prose worth migrating (`description`, `installation`, `compatibility`) versus metadata to leave alone, plus the ProjectClass no-`id`/no-button case and the fact that `installation`/`compatibility` often carry obsolete rows to drop rather than migrate. Note that a mandatory install-time step should be replaced by a pointer at the new page instead of being blanked. Add the matching instruction to the xwiki-doc-convert extraction step. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications
participants (1)
-
XWiki Notifications