Some knowledge files in .mex/context/ and .mex/patterns/ never become Wiki entities, and
nothing reports it. Their content and groundings are unreachable through wiki query,
wiki for-code and the Hub's Context view.
1. context/stack.md and project-specific context files are always skipped
wiki migrate classifies context files through a fixed table, CONTEXT_ROLES
(src/wiki/migration/classify.ts:101). The table covers architecture, conventions, setup,
risks and decisions. context/stack.md is not in it, even though setup writes it for
every project. Neither are the domain files that population creates (routing.md,
payouts.md, …). Each one gets:
No classification rule determines the type of context/stack.md. … Migration leaves this file unchanged.
Measured on two scaffolds that setup populated:
| scaffold |
context files skipped |
groundings in skipped files |
| Hono |
routing.md, rpc-client.md, stack.md |
8 |
| project set up with 0.8.2 |
stack.md + 3 domain files |
17 |
On Hono, 19% of the questions in an evaluation set could not be answered from the Wiki at all
because their answer lives in one of these files.
2. Patterns added after setup are never adopted
On mex itself, three pattern files (hub-first-run-onboarding.md,
syntax-extractor-review.md, usage-telemetry.md) have no entity. wiki migrate --dry-run
shows migration would adopt all three. Nothing re-runs migration after setup, and neither
mex check nor wiki validate says a knowledge file is outside the Wiki.
Expected behavior
- Add a rule for
context/stack.md (it is a list of technologies; guide, or a file-level
entity with a new stack type, are both plausible).
- Give project-specific context files a default rather than an abstain. For example, adopt a
file-level entity typed from frontmatter, or fall back to a generic type, so population output
is always indexed.
- Report un-adopted knowledge files as a
check or wiki validate diagnostic, with
wiki migrate as the remediation.
Some knowledge files in
.mex/context/and.mex/patterns/never become Wiki entities, andnothing reports it. Their content and groundings are unreachable through
wiki query,wiki for-codeand the Hub's Context view.1.
context/stack.mdand project-specific context files are always skippedwiki migrateclassifies context files through a fixed table,CONTEXT_ROLES(
src/wiki/migration/classify.ts:101). The table coversarchitecture,conventions,setup,risksanddecisions.context/stack.mdis not in it, even though setup writes it forevery project. Neither are the domain files that population creates (
routing.md,payouts.md, …). Each one gets:Measured on two scaffolds that setup populated:
routing.md,rpc-client.md,stack.mdstack.md+ 3 domain filesOn Hono, 19% of the questions in an evaluation set could not be answered from the Wiki at all
because their answer lives in one of these files.
2. Patterns added after setup are never adopted
On mex itself, three pattern files (
hub-first-run-onboarding.md,syntax-extractor-review.md,usage-telemetry.md) have no entity.wiki migrate --dry-runshows migration would adopt all three. Nothing re-runs migration after setup, and neither
mex checknorwiki validatesays a knowledge file is outside the Wiki.Expected behavior
context/stack.md(it is a list of technologies;guide, or a file-levelentity with a new
stacktype, are both plausible).file-level entity typed from frontmatter, or fall back to a generic type, so population output
is always indexed.
checkorwiki validatediagnostic, withwiki migrateas the remediation.