[xwiki/xwiki-dev-llm] ba9e00: [Misc] Spend the index entry budget on the symptom...
Branch: refs/heads/okf-index-lean Home: https://github.com/xwiki/xwiki-dev-llm Commit: ba9e0036d28251b07243a986db72399b157f3c34 https://github.com/xwiki/xwiki-dev-llm/commit/ba9e0036d28251b07243a986db7239... Author: Vincent Massol <[email protected]> Date: 2026-09-15 (Tue, 15 Sep 2026) Changed paths: M xwiki/okf/index.md Log Message: ----------- [Misc] Spend the index entry budget on the symptom, not on a rule digest The sweep shortened every entry, and for the ~13 topics `okf/index.md` is the only discovery path for, that dropped something the length had been carrying by accident: the symptom a developer arrives with. The old `server-side-rendering` entry held the literal *"cannot be used inline"* error, so the developer reading that message hit the topic dead-on; its replacement described the cause instead. * Name the arriving symptom in the 10 entries that had one to name — the standalone-macro error, `Unknown macro: <id>` from an under-declared wiki macro, a `DocumentationClass` sweep skipping landing pages, a subwiki offering only main-wiki users, a macro *parameter* left pointing at the old name, a lexicographic range filter, `getLastError()`, `$discard`, the pnpm lockfile rewrite, and the registration a new bundle needs. * Leave the name-shaped entries (`naming`, `release`, `module-lifecycle`, `check-binary-not-source-compatibility`) alone: nobody arrives at those with an error message. * Stay inside the 240-byte per-entry budget throughout — the bytes come out of generic words, not out of the symptom. 8488 → 9209 bytes, still well under the 11000-byte file budget. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Commit: 7b482d71438283a65a9d6ef45649189e2d940ed2 https://github.com/xwiki/xwiki-dev-llm/commit/7b482d71438283a65a9d6ef4564918... Author: Vincent Massol <[email protected]> Date: 2026-09-15 (Tue, 15 Sep 2026) Changed paths: M xwiki/okf/index.md Log Message: ----------- [Misc] Let the ADR own the question its neighbour was catching An A/B routing test of the index (15 questions, a fresh agent given the index text and nothing else) found one question the sweep had moved: "why does Revapi not complain about X" reached `backward-compatibility` instead of the ADR. Both entries claimed the negative — the ADR said Revapi "enforces binary and semantic but not source compatibility", and its neighbour said Revapi "checks and does not". Re-running the question on the old index returns both answers too, so this was a coin flip either way rather than a regression the sweep introduced. * Give the ADR the symptom shape — *why Revapi stays silent on a change that breaks a caller's source* — and leave the neighbour the positive half of its scope, what an API may change and what Revapi checks. * Three re-runs on the amended index now route to the ADR every time. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Compare: https://github.com/xwiki/xwiki-dev-llm/compare/c217302896f0...7b482d714382 To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications
participants (1)
-
XWiki Notifications