WORK-051
ID:WORK-051Status:in-progress

Editor Package Awareness

Priority:highComplexity:complexMilestone:v1.0.0Source:SPEC-001
main View source

Criteria completion

Criteria completion: 3 of 8 (38%) checked; history from Mar 24 to Mar 240%25%50%75%100%Mar 24Mar 24

Relationships

Implements 1
Related 1
Branches 3
main current in-progress
claude/file-naming-convention-LJdwR in-progresschangeset-release/main in-progressclaude/align-sidenav-styling-4MuxV in-progress
History 6
  1. e900a90
    Created (in-progress)by bjornolofandersson
  2. f262d7b
    Content editedby Claude
  3. 2637549
    Content editedby Björn Andersson
  4. a129a9e
    Content editedby Claude
  5. a333007
    • ☑ Editor loads packages from `refrakt.config.json` on startup using `loadRunePackage()` + `mergePackages()`
    • ☑ Package runes appear in the rune palette (`/api/runes` endpoint)
    • ☑ Package runes parse and render correctly in the preview panel
    by Claude
  6. 2f24c14
    Created (ready)by Claude
    Add work items for SPEC-001 and SPEC-002

Summary

The editor (packages/editor/) only sees core runes. It doesn't load community or official packages from refrakt.config.json, so package runes don't appear in the palette, fail to parse in preview, and can't be edited. This gap existed before the official packages breakout but is now critical — official @refrakt-md/* runes like hero, character, and api are invisible to the editor.

The SvelteKit plugin (packages/sveltekit/src/plugin.ts) and CLI inspect command already load packages via loadRunePackage() + mergePackages(). The editor needs the same treatment.

Acceptance Criteria

  • Editor loads packages from refrakt.config.json on startup using loadRunePackage() + mergePackages()
  • Package runes appear in the rune palette (/api/runes endpoint)
  • Package runes parse and render correctly in the preview panel
  • Rune palette groups package runes by package name (using RunePackage.displayName)
  • CHILD_RUNES set is derived from rune schemas rather than hardcoded
  • RUNE_CATEGORIES map uses package displayName for package runes instead of hardcoded categories
  • Package RuneConfig entries are included in the theme config sent to the client for preview rendering
  • Package postTransform hooks survive the server→client serialisation boundary

Approach

  1. Pass RefraktConfig (or config.packages) through to startEditor() via EditorOptions
  2. Call loadRunePackage() + mergePackages() in packages/editor/src/server.ts on startup
  3. Feed merged tags into Markdoc.transform() in packages/editor/src/preview.ts
  4. Feed merged rune metadata into the /api/runes response
  5. Feed merged RuneConfig entries into the themeConfig sent to the client
  6. Replace hardcoded CHILD_RUNES with schema-derived detection (runes with a parent tag are children)
  7. Replace hardcoded RUNE_CATEGORIES with dynamic grouping: core runes keep functional categories, package runes use RunePackage.displayName

References

  • SPEC-001 (Community Runes — Product Boundaries)
  • WORK-001 (Official Rune Packages — Editor impact section)