Branch: refs/heads/okf-wiki-application-data Home: https://github.com/xwiki/xwiki-dev-llm Commit: af5589c0f04afbd38067da7591e9ce80d6b490f6 https://github.com/xwiki/xwiki-dev-llm/commit/af5589c0f04afbd38067da7591e9ce... Author: Vincent Massol <[email protected]> Date: 2026-08-31 (Mon, 31 Aug 2026) Changed paths: M .claude-plugin/marketplace.json M kimi.plugin.json M opencode.jsonc M xwiki/.claude-plugin/plugin.json M xwiki/instructions/xwiki-org.md A xwiki/okf/architecture/wiki-application-data.md M xwiki/okf/conventions/frontend.md M xwiki/okf/index.md M xwiki/skills/xwiki-review/SKILL.md Log Message: ----------- [Misc] Add an OKF topic for stored data in a wiki application * New `okf/architecture/wiki-application-data.md`. Three traps that a review of a real XClass+wiki-page application hit, none of which had an OKF home: - A list property that is neither `multiSelect` nor large storage is stored as a `StringProperty` (`ListClass.newProperty`) in `xwikistrings.XWS_VALUE`, a VARCHAR, so HQL/XWQL range filters on it compare text. Single-character codes sort as intended, which is what hides it until values differ in length. - A generated `Entry001` name derived from the pages that already exist races for the whole editing session, because the page appears only on save. - A wiki-page migration is idempotent for free if it drops the object it matched on; what it still needs is a completion count. Plus the entry-template trap: a template missing the marker class its queries use produces entries invisible to every query. * Grounded in platform source (`ListClass`, `xwiki.hbm.xml`), verified rather than extrapolated from the one application reviewed. * Cross-reference `[[performance]]` for bounding the migration instead of restating its pagination rule, so the batching rule keeps one home. * `okf/conventions/frontend.md`: the WCAG 2.2 AA bullet stated the commitment but no operational rule, so add the three traps for markup emitted from a wiki page — naming a control (a `<dt>` term and a prompt in `value` are not names, and a prompt in `value` also submits as data), `[[image:]]` alt text defaulting to the filename, and `col-xs-*` not being a responsive layout. Accessibility already lives here, so this extends that entry rather than adding a second home. * `skills/xwiki-review`: stop the accessibility brief asserting a WCAG version of its own. It claimed the OKF had no accessibility topic and named WCAG 2.1, while `frontend.md` has covered accessibility at 2.2 — so a reviewer was being told to cite criteria against a standard the project does not hold. It now reads the level from `frontend.md` and is told never to state it from memory, which is what keeps it from drifting again on the next re-commit. * `skills/xwiki-review`: the data & migration angle claimed the stored-data rules had no OKF home, which this commit makes false, and its routing fired only on `*.hbm.xml`, migrator classes, Solr schema and store code — so it could never run on a XAR-only extension, the very place the new topic applies. Add the XClass / generated-name / wiki-page-migration trigger and cite the new file; narrow the remaining skill-owned marker to Java store and mapping changes. * Describe both OKF changes in `okf/index.md`; add the topic name only to the always-on map in `instructions/xwiki-org.md` (+1 line, routing only). * Bump the plugin version so installed plugins pull the change. 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