* feat(landing-page): localize plugins library across 18 locales
PR #2926 shipped the new `/plugins/` library hub + four kind sub-routes
+ detail pages, but the chrome was English-only — visitors landing on
`/zh/plugins/` saw the old marketplace registry placeholder rendered
by the catch-all instead, and detail pages rendered identical English
copy regardless of locale prefix. This PR brings the plugin surface
to feature parity with `/zh/skills/`, `/zh/templates/`, `/zh/systems/`,
`/zh/craft/`.
## What changes
- New `app/_lib/plugins-i18n.ts` — single source for all plugin chrome
copy (hub, list pages, chip rails, share dialog, detail-page meta
labels). English baseline + 17 locale overrides keyed on
`LandingLocaleCode` (the same short-code shape `localeFromPath()`
returns). Missing keys per locale fall back to English so a
partially-translated locale still renders sensibly. Translations
cover hub copy, four tile titles + blurbs, seven artifact-kind
labels + descriptions, 23 scene-subcategory labels, 18 detail-page
chrome strings, and a six-key share-dialog table with a
per-locale `shareTemplate({title, url})` function (translated for
every locale where `_lib/i18n.ts` already had one — same voice).
- `app/pages/plugins/{,templates/,templates/[kind]/,skills/,systems/,
craft/,[slug]/}/index.astro` — every hardcoded English string now
reads `getPluginsCopy(locale)` keys. Page logic and routing
unchanged.
- New short-code wrappers under `app/pages/[locale]/plugins/` — six
files (hub + three sub-routes + `[kind]/` and `[slug]/`) following
the same pattern `[locale]/skills/index.astro` already uses: each
re-exports the canonical page component and adds a per-locale
`getStaticPaths()` so the build emits 17 locale prefixes per
plugin route. Total plugin-route prerender count goes from ~390 to
~7 000, matching the existing skill/template scaling.
- Catch-all (`[locale]/[...path].astro`) — old `getPublicPlugins` /
`getRegistryCounts` registry rendering removed (placeholder UI
that was never wired to a real marketplace data source). Plugin
routes now live exclusively under `[locale]/plugins/...` short-code
wrappers, so the catch-all stops claiming `'plugins'` as a route
root. The dead-code path also drops a `pluginCounts.all` reference
the title row was reading.
- `.plugins-tile-grid` styles promoted from a scoped `<style>` in the
default-locale hub to global `app/sub-pages.css` so the
short-code wrapper renders the same hub markup without re-mounting
per-page CSS — `display: contents`-style scoping pitfalls in
Astro's per-component CSS scoping made this the cleanest fix.
## Surface area
- [ ] **UI** — new page / dialog / panel / menu item / setting / empty state in `apps/web` or `apps/desktop`
- [ ] **Keyboard shortcut** — new or changed
- [ ] **CLI / env var** — new `od` subcommand or flag, new `tools-dev` flag, or new `OD_*` env var
- [ ] **API / contract** — new `/api/*` endpoint, new SSE event, or changed shape in `packages/contracts`
- [ ] **Extension point** — new entry under `skills/`, `design-systems/`, `design-templates/`, or `craft/`, or change to the skills protocol
- [ ] **i18n keys** — new translation keys (full plugin chrome added across all 18 locales)
- [ ] **New top-level dependency** — adding any new entry to the **root** `package.json`
- [ ] **Default behavior change** — changes what existing users experience without opting in
- [x] **None** — landing-page-only restoration of i18n parity for the plugin surface
## Validation
- `pnpm --filter @open-design/landing-page typecheck` → 0 errors
- `pnpm --filter @open-design/landing-page build:static` → 16 127 pages
built (+6 584 over current main: ~388 plugin detail pages × 17
locale prefixes plus the hub + four sub-routes × 17 locales).
- `copy-example-html.ts` reports `266 entry files + 65 referenced
files`, identical to before — no regression in the asset-mirroring
pipeline.
- Local Playwright smoke (`/zh/plugins/...`):
- `/zh/plugins/` renders `<title>插件库 · Open Design</title>`,
label `插件库`, h1 `407 个可组合的构件。`, four tiles labelled
`模板 / 技能 / 设计系统 / 工艺`.
- `/zh/plugins/templates/video/` renders h1 `48 视频`, scene chips
`全部 / 动效 / 短视频 / 营销 / 产品 / 数据讲解`.
- `/zh/plugins/example-article-magazine/` share dialog renders
`复制下面的文案、然后跳到你想分享的平台粘贴即可` etc., share
template auto-interpolates plugin title + URL into Chinese voice.
- All 18 locale prefixes (`/zh`, `/zh-tw`, `/ja`, `/ko`, `/de`,
`/fr`, `/ru`, `/es`, `/pt-br`, `/it`, `/vi`, `/pl`, `/id`, `/nl`,
`/ar`, `/tr`, `/uk`) → 200 across hub + four sub-routes + sample
detail page.
- English `/plugins/` unchanged (default-locale path bypasses the
`[locale]/...` wrapper).
* feat(landing-page): finish plugins i18n chrome across 18 locales
The first localization pass shipped a partial fix: hub headings, lead
copy, two-level page chrome, detail-page metadata labels, the share
dialog, and the chip rail were still falling back to English on every
non-English locale because plugins-i18n.ts only filled a chrome slice
for `zh` and the file header even claimed "7 artifact-kind labels and
25 scene-subcategory labels are translated" for every locale that did
not yet have those blocks.
Three changes close the visible gap:
1. plugins-i18n.ts: fills the 27 still-missing chrome fields per locale
for zh-tw / ja / ko / de / fr / ru / es / pt-br / it / vi / pl / id /
nl / ar / tr / uk. Includes the 7-key category map, the 23-key
subcategory map, hubHeading / hubLead, the 4 *Label / *Heading /
*Lead triples for the templates / skills / systems / craft hub
pages, the 4 tile blurbs, the 4 browse buttons, sceneLabel, allChip,
the 12 detail-page metadata labels (mode / scenario / platform /
surface / author / manifest id / tags / preview caption / find on
GitHub / homepage / open in new tab) and bucket label map, the
detail share dialog (title / copy link / jump-to), and the
header-side nav.plugins entry. zh receives the same 11 detail-page
and share-dialog labels it was also missing.
2. header.tsx + site-footer.astro: routes the hardcoded "Plugins /
Templates / Skills / Systems / Craft" labels through `nav.*` from
HeaderCopy, so every locale gets its own dropdown trigger and
footer column. Adds `nav.plugins` to HeaderCopy and fills it in 18
locales with the local form ("插件" / "プラグイン" / "Plugins" /
"Plug-ins" / "Plaginy" / "الإضافات" / etc).
3. plugin-row.astro + content-i18n.ts: chip rail. The bundled-plugin
branch now runs raw `mode` / `scenario` slugs through the shared
localizeTaxonomyValue, and that helper now also consults the
plugins-i18n subcategory map before giving up. localizeTaxonomyValue
now returns undefined on a true miss instead of the unknownTag
placeholder, so chips drop quietly instead of showing "Category" /
"分類" / "Categoría" for taxonomy slugs we have not localized yet.
Callers that genuinely want the placeholder (`localizeContentTag`,
blog `category`, system noun) still keep the explicit fallback.
Out of scope and tracked separately: per-plugin title and description
in plugins/_official/* (author-supplied English metadata, ~401 plugins
without an i18n schema in the manifest yet — needs RFC + tooling
before the manifests can be expanded), and adding the long tail of
mode / scenario / category slugs (`code-migration`, `plugin-sharing`,
`tune-collab`, `live-artifacts`, `engineering`, ...) to TAXONOMY_TERMS
so chips render localized labels for every taxonomy value rather than
dropping silently.
* feat(landing-page): cover plugins chip rail long-tail taxonomy slugs
PR #3010's first round localized the high-frequency mode/scenario
chips (prototype, video, image, marketing, design, ...) but left the
~37 mode/scenario and 14 category slugs that show up in real `od.*`
metadata — code-migration, plugin-sharing, design-system, planning,
scenario, refine, discovery, handoff, token-map, tune-collab, orbit,
live-artifacts, engineering, healthcare, hr, sales, support,
default-router, downstream-export, figma-migration, media-generation,
plugin-authoring, validation, 3d-shaders, animation-motion,
audio-music, creative-direction, design-systems, diagrams, documents,
image-generation, marketing-creative, screenshots, slides,
video-generation, web-artifacts, ... — falling through to undefined
and dropping their chip silently on every non-English locale.
The data layer is the source of truth here, so this expansion lands
in `content-i18n.ts:TAXONOMY_TERMS` / `CATEGORY_LABELS` rather than
the plugins-i18n catalog: a single dictionary entry per slug fans out
to every chip-rail consumer (catalog rows, detail metadata, the
templates/[kind] facets) without each consumer touching its own copy.
Translations cover all 17 non-`en` locales. Brand and product nouns
(Figma, Open Design, BYOK, plugin) stay literal; technical taxonomy
slugs get short equivalents that read as chips rather than full
prose. The result on `/ja/plugins/skills/` matches `/plugins/skills/`
chip-for-chip (30 chips both sides) instead of dropping 27 of them
the way the previous iteration did.
* feat(landing-page): read manifest title_i18n / description_i18n on bundled plugins
PR #3010's prior rounds localized chrome and chip rails but the
catalog's most prominent text — each row's plugin name and blurb —
stayed English on every non-English locale. The plugin manifest
schema (`packages/contracts/src/plugins/manifest.ts`) has supported
`title_i18n` and `description_i18n` (Record<locale, string>) on every
manifest from spec v1; ~24 of the 401 first-party manifests already
carry one for `zh-CN`. The reader was just never wired to use them.
This change does the reader half: bundled-plugins.ts captures the
two i18n maps off each `open-design.json`, plugin-row.astro and the
detail page resolve them at render time via two new helpers
(`resolveBundledTitle`, `resolveBundledDescription`) that mirror the
short→long fallback chain documented in the manifest spec
(`htmlLang` like `zh-CN` → short `LandingLocaleCode` like `zh` →
primary tag → `en` → English baseline). The static-paths pass still
runs once for all locales — it has to, since each manifest produces
one URL — but the title/description shown on the rendered page now
reads the locale off `Astro.url.pathname` and picks the right entry
out of the maps.
Verified locally: `/zh/plugins/example-card-twitter/` now reads
"Twitter 分享卡 / 推特金句 / 数据卡, 适合配推文" from the manifest's
existing `zh-CN` block instead of the English baseline.
Plugin-data half follows in a separate commit. The 17 non-English
locales × 401 manifests need backfilling so the reader has something
to resolve to; that's data, not schema, and lands as a sequence of
manifest patches rather than tangled with this code change.
* feat(plugins): translate scenarios bucket title/description across 17 locales
Closes the first chunk of #3028. Eleven scenarios plugins (the
default-scenario bundle for each taskKind: code-migration,
figma-migration, media-generation, new-generation, tune-collab,
plugin-authoring; the default design router; the React / Vue /
Next.js downstream-export starters; and the Refine baseline) get
title_i18n + description_i18n filled for all 17 non-English locales
the landing page serves (zh-CN, zh-TW, ja, ko, de, fr, ru, es,
pt-BR, it, vi, pl, id, nl, ar, tr, uk).
The reader landed in 7ddfe36; this commit is data-only. taskKind
slugs that other docs reference by name (`code-migration`,
`figma-migration`, `tune-collab`, etc.) stay literal in the
descriptions so cross-references still resolve. Brand nouns —
Open Design, Next.js, React, Vue, Figma — also stay literal.
`/ja/plugins/od-code-migration/` now reads
"コードマイグレーション（デフォルトシナリオ）" instead of the English
baseline; `/zh/plugins/skills/` shows "代码迁移（默认场景）" in the
catalog row.
Remaining buckets (image-templates 45, video-templates 50,
examples 140, design-systems 142 = 377 plugins) follow in
subsequent commits in this PR.
* fix(landing-page): drop CJK template wrap when source name is still English
The Chinese / Japanese / Korean fallback templates for craft, skill,
template, system, plugin, and blog text splice the source `name` /
`title` into a CJK sentence frame: ``${name}工艺规则``,
``Open Design 指南：${topic}``, ``${name} は…のスキルです``. When the
underlying SKILL.md / craft markdown / blog frontmatter still ships
an English name (true for ~95% of the catalog today), that produces
mid-sentence script straddling on `/zh/...`, `/zh-tw/...`, `/ja/...`,
`/ko/...` like:
H1 : "Editorial typography hierarchy工艺规则"
Lead : "这条 Open Design 工艺规则定义 Editorial typography hierarchy
的执行标准…"
Plug : "video 插件 · 3D Animated Boy Building Lego"
That reads worse than the all-English fallback, because the visitor
parses the page in two scripts at once.
Adds a `nameNeedsEnglishFallback` guard that fires for the four CJK
locales whenever the spliced-in name has no CJK characters of its
own, and threads it through every `localizeXxxText` helper:
craft, template, system, plugin, skill, blog. When it fires the
helper returns the raw English content untouched, so the section
renders end-to-end in one language. Chrome (header, footer, breadcrumb,
buttons, share dialog) keeps its CJK rendering — only the
title-and-lead block falls back.
Side benefit: the same guard kicks in on the long tail of plugin
manifests still pending `title_i18n` / `description_i18n` backfill
(tracked in #3028), so `/zh/plugins/<bundled>/` no longer pairs a
"video 插件 · 3D Animated Boy Building Lego" title with a Chinese
breadcrumb. The page reads "3D Animated Boy Building Lego" + the
English manifest description, while header / footer / breadcrumbs
stay localized. Once a manifest ships its i18n maps, the chrome and
body re-converge automatically.
Non-CJK non-Latin scripts (ar, vi, ...) keep the previous behavior —
their templates already read tolerably with English names. If that
turns out to be wrong on a real audit, the same guard generalizes by
adding the matching Unicode range and locale set.
* feat(plugins): translate image-templates bucket title/description across 17 locales
44 of 45 image-templates plugins get title_i18n + description_i18n
filled for all 17 non-English locales (zh-CN, zh-TW, ja, ko, de, fr,
ru, es, pt-BR, it, vi, pl, id, nl, ar, tr, uk). Generated via Claude
Sonnet 4.5 over the OpenRouter gateway, ~$1.38 in API spend, 156s
wall-clock. Brand and cultural references stay literal (Open Design,
Lego, Hanfu, Showa, Pokémon, Black Myth: Wukong). Long AI generation
prompts collapse to a 1-2 sentence summary capturing what the plugin
does — the description doubles as catalog blurb on the landing site,
not as the actual generation prompt (which lives in example.html /
the manifest's preview entry).
Skipped: `profile-avatar-realistically-imperfect-ai-selfie` returned
malformed JSON on three retries; will rerun with a tighter prompt in
a follow-up commit. Catalog rows for that plugin keep falling back to
the raw English fields per #3010's reader change, so nothing breaks.
Tracking: closes the image-templates row in #3028.
* feat(plugins): translate video-templates bucket title/description across 17 locales
49 of 50 video-templates plugins get title_i18n + description_i18n
filled for the 17 non-English landing locales. Generated via Claude
Sonnet 4.5 over OpenRouter, ~$1.47 in API spend, 177s wall-clock.
HyperFrames templates, the Three Kingdoms cinematic series, the
Seedance/short-film prompts, and the K-pop / wuxia / anime variants
all get a 1-2 sentence catalog blurb in each locale; brand and
cultural tokens (Black Myth: Wukong, Hanfu, Showa, Pokémon, Three
Kingdoms / 三国志, Lego, Disney, K-pop, HyperFrames) stay literal.
Skipped: `live-action-anime-adaptation-water-vs-thunder-breathing-duel`
returned malformed JSON on three retries; will rerun in followup.
Falls back to the raw English fields per the reader landed in 7ddfe36.
Tracking: closes the video-templates row in #3028.
* feat(plugins): translate examples bucket (117/140) title/description across 17 locales
117 of 140 examples plugins get title_i18n + description_i18n filled
for the 17 non-English landing locales. Generated via Claude Sonnet
4.5 over OpenRouter, $3.94 in API spend, ~13 min wall-clock at
8-way concurrency. Existing zh-CN translations on 24 manifests are
preserved (the merge keeps author-supplied entries and only adds
missing locales).
23 of 140 returned malformed JSON on three retries — the output
likely hit the 4000 max_tokens ceiling on plugins whose description
balloons across 17 locales. Those manifests fall back to English on
non-`en` rendering per the reader landed in 7ddfe36, and will rerun
in a follow-up commit with a larger token budget and a stricter
output schema.
Tracking: closes 117/140 of the examples row in #3028; the remaining
23 stay open in that issue's failure list.
* feat(plugins): translate design-systems bucket (141/142) title/description across 17 locales
141 of 142 design-systems plugins get title_i18n + description_i18n
filled for the 17 non-English landing locales. Generated via Claude
Sonnet 4.5 over OpenRouter, $2.55 in API spend, 301s wall-clock at
8-way concurrency.
Translator script gained two improvements between examples and this
bucket:
- max_tokens bumped from 4000 to 8000 so 17-locale outputs stop
truncating on the long-tail manifests with verbose descriptions
- a balanced-brace JSON extractor that pulls the outermost `{ ... }`
from the response, tolerating trailing prose Claude occasionally
appends after the JSON object.
Result: only 1 manifest (`totality-festival`) failed parse this
batch, down from ~16% on the examples bucket. The next commit
re-runs the prior buckets' failures with the improved script.
Tracking: closes 141/142 of the design-systems row in #3028.
* fix(plugins): backfill 4 plugins that retried green after JSON extractor improvement
dcf-valuation, social-media-dashboard, wireframe-sketch (examples
bucket) and live-action-anime-adaptation-water-vs-thunder-breathing-duel
(video-templates bucket) parse cleanly under the balanced-brace
extractor introduced for the design-systems batch. The remaining
22 failures from the prior runs hit a different parse mode (Claude
emitting unescaped double quotes inside string values when the source
description contains its own English quotes like 'make it professional');
those will need a tighter prompt and rerun.
* fix(plugins): translate the last 22 plugins with quote-handling prompt fix
The 22 stuck plugins all carried English / Chinese double-quoted
phrases inside their description (\"make it professional\",
\"What's inside\", \"电子杂志 × 电子墨水\") that Claude was emitting
back inside JSON string values without escaping, breaking the parse.
Added one rule to the translator prompt — never use a straight double
quote inside a translated string, prefer single quotes / curly quotes
/ CJK 『 』 / 《 》 — and the previously stuck batch sailed through
clean: 22/22 ok, 0 retries, $0.85.
This closes the long tail of #3028:
- scenarios 11/11 ✓
- image-templates 45/45 ✓
- video-templates 50/50 ✓
- examples 140/140 ✓
- design-systems 142/142 ✓
- atoms N/A (filtered from public catalog)
All 388 catalog-visible plugins now ship title_i18n + description_i18n
for all 17 non-English locales the landing page serves.
* fix(plugins): clean up four review-flagged i18n data issues
- apps/landing-page/app/_lib/plugins-i18n.ts:759 — Polish bucket
label `examples: 'Przyklad'` was missing the diacritic; every
other Polish string in the same block uses proper diacritics.
Restore to 'Przykład'. (Reviewer: looper #4364985878.)
- video-templates/cinematic-route-navigation-guide — German
title_i18n.de was a byte-for-byte copy of en ("Cinematic Route
Navigation Guide") while the German description was already
translated. Replace with "Cinematischer Routen-Navigationsleitfaden"
to match the German voice the description sets.
- video-templates/hollywood-haute-couture-fantasy-video-prompt —
Dutch title_i18n.nl was identical to en for the same reason.
Translate the trailing noun phrase: "Hollywood Haute Couture
Fantasy Videoprompt" (mirrors the Dutch description's compound
word style).
- video-templates/video-seedance-three-kingdoms-guanyu-slaying-yanliang —
Korean Hangul `돌진` had leaked into the Turkish description (a
translation-pipeline artifact where the model copied the verb
from the Korean output without translating it). Replace
"saflarına돌진 eder" with the idiomatic Turkish "saflarına dalar".
All four are data-only fixes against existing manifests; no schema
changes, no reader changes. typecheck stays at 0 errors.
* fix(landing-page): localize aria-labels, alt text and BreadcrumbList JSON-LD on plugin detail page
The PR's prior rounds left six accessibility / structured-data
surfaces on `/{locale}/plugins/<slug>/` either entirely English or
mixing English chrome with the localized plugin title. Reviewer
flagged each one across multiple loops; this commit clears them all:
1. `aria-label` on the open-in-new-tab popout no longer reuses the
visible label `pcopy.detailOpenInNewTab` (which carries the
decorative `↗`). Added `detailOpenInNewTabAria` — same wording,
no glyph — and the `<a aria-label>` consumes that key. The
visible link text still ends in `↗`.
2. `<nav class="breadcrumb" aria-label="Breadcrumb">` now reads
`aria-label={pcopy.breadcrumbLabel}`. Eighteen locales filled
("面包屑导航", "パンくずリスト", "Brotkrumen-Navigation",
"Fil d'Ariane", "مسار التنقل", "İçerik haritası", ...).
3. Share-dialog `<button aria-label="Close">` now reads
`aria-label={pcopy.shareDialogClose}`. Eighteen locales filled
("关闭", "閉じる", "Cerrar", "Закрыть", "إغلاق", ...).
4. Three template-literal a11y strings (`${pluginTitle} preview`,
`Open interactive preview for ${pluginTitle}`, `${pluginTitle}
interactive preview`) become function calls
(`pcopy.previewImageAlt(t)`, `previewSummaryAria(t)`,
`previewIframeTitle(t)`) so the sentence frame around the
plugin title rotates with the page locale. Two `<img alt>` call
sites (the static preview at line 210 and the click-to-expand
thumbnail at line 179) both consume `previewImageAlt`.
5. `BreadcrumbList` JSON-LD position-2 now reads
`name: pcopy.hubLabel` instead of hardcoded English `"Plugins"`.
The visible breadcrumb at line 105 already renders
`pcopy.hubLabel`; this aligns the structured data with the
rendered chrome on every locale.
The new function-typed keys deliberately interpolate `pluginTitle`
(which is itself locale-resolved via `resolveBundledTitle`) so the
mixed-language guard from commit 002d457 is preserved: a manifest
without a per-locale title still flows through to a coherent
single-language a11y string because `pluginTitle` falls back to
English along with the rest of the section.
apps/landing-page typecheck stays at 0 errors.
Closes reviewer threads:
- #pullrequestreview-4364985878 (Open in new tab aria)
- #pullrequestreview-4368926224 (Polish typo + plus mixed-language alt/aria)
- #4373... (BreadcrumbList JSON-LD)
- #4374... (aria-label="Close" + aria-label="Breadcrumb")
* fix(landing-page): redirect legacy fa/hu/th /plugins/ paths to canonical
When the new `/{locale}/plugins/...` short-code wrappers landed, the
legacy catch-all `pages/[locale]/[...path].astro` dropped `'plugins'`
from its `paths` list. That intentionally avoids serving stale
marketplace-registry placeholder routes for the modern landing
locales — but it also takes `/fa/plugins/`, `/hu/plugins/`, and
`/th/plugins/` from 200 to 404, because those three legacy locales
live only in the old `_lib/i18n.ts:LOCALES` set and are not part of
`LANDING_LOCALES` (the modern 18-locale list the new wrappers serve).
Three `301`s in `_redirects` send those legacy URLs to the canonical
English `/plugins/...` so SEO and inbound links keep working until
the legacy locale set is retired entirely.
Reviewer thread (#pullrequestreview-4364052045) flagged this as a
non-blocking regression across multiple loops; this commit closes it.
* ci(landing-page): add merge_group trigger so the queue can clear PRs
`landing-page-ci.yml` only fired on `pull_request` and `push:main`,
which meant the required `Validate landing page` and
`Strict PR visual tests` checks never dispatched against the
`merge_group` ref the merge queue creates. The queue then sat at
"awaiting checks" until it timed out and ejected the PR (the
deadlock observed during the 5/26 release window).
Adding a `merge_group: { types: [checks_requested] }` trigger to
the same workflow lets the queued ref reuse the existing job graph,
matching the pattern in `ci.yml` which already wires `merge_group`.
Also drops `plugins/**` into the same paths filter as `pull_request`
since the new bundled-plugins reader (commit 7ddfe364) consumes
those manifests' `title_i18n` / `description_i18n` maps and the
landing-page CI must rerun when manifest data changes.
---------
Co-authored-by: Joey-nexu <joeylee12629@gmail.com>
Use DESIGN.md telemetry palette values in tokens.css and the
components.html fixture. Document the --success/--danger mapping in
DESIGN.md so spec readers and CSS consumers stay aligned.
* feat(landing-page): plugin detail page interactive preview + share dialog
The new `/plugins/<manifest-id>/` detail page that shipped in #2926
landed without the two affordances PR #2679 added to the legacy
`/skills/<slug>/` and `/templates/<slug>/` pages: a click-to-expand
iframe of the live artifact, and a share dialog with brand-keyword
copy plus four-channel jump buttons (X / LinkedIn / Reddit /
Facebook). This restores both, sourced from the bundled-plugin
manifest under `plugins/_official/<bucket>/<slug>/open-design.json`.
## Interactive preview
Three preview-type behaviours, gated on `od.preview.type`:
- `video` (Cloudflare Stream URLs already in the manifest) —
inline `<video controls poster=...>` with the playable MP4 as
`<source>`. Detail-page row is unchanged from #2926; controls
double as the open-full affordance.
- `html` (a local `example.html` referenced by `od.preview.entry`,
only the `examples/` bucket today) — `<details>` toggle wraps the
poster image as the summary; clicking opens a sandboxed
`<iframe>` that loads the entry HTML lazily, with an
"Open in new tab ↗" pill in the frame's top-right corner so the
artifact can be inspected at full screen.
- `image` or no entry — static `<img>` (existing behaviour).
`copy-example-html.ts` is extended to mirror the local entry and any
`./assets/...` siblings to `out/plugins/<manifest-id>/<entry>` so the
iframe URL resolves on Cloudflare Pages instead of SPA-falling-back to
the homepage. The four examples carrying sibling-asset references
(flowai-live-dashboard-template, trading-analysis-dashboard-template,
open-design-landing, open-design-landing-deck) all render in-place.
## Share dialog
Same `<dialog data-share-dialog>` markup the legacy detail pages use,
so the global click handlers in `header-enhancer.astro`
(`data-share-open` / `data-share-copy` / `data-copy-link`) wire up
the open / copy actions automatically — no extra client bundle. Four
platform jumps (X / LinkedIn / Reddit / Facebook) plus a Copy-text /
Copy-link pair, with a single English template for now (the new
`/plugins/...` routes only generate English pages; localisation can
land alongside the i18n catch-all follow-up).
## Bundled in
- The `copy-example-html.ts` sibling-assets fix from open PR #2880.
Without it the existing `/skills/<slug>/` iframe still 404s on
Cloudflare Pages for after-hours-editorial-template and the four
others; bundling it here means the same script handles both
sources in one pass and sidesteps two PRs touching identical
helper code.
* fix(plugins): remove dangling preview.entry from example-hyperframes
The hyperframes example folder ships a SKILL.md (it's an instruction
manual for using the HyperFrames HTML format) but no runnable
`example.html`. The manifest still claimed `preview.type: html` /
`preview.entry: ./example.html`, which made the marketing site try
to iframe a non-existent file and forced the preview pipeline into
its `Path 3` fallback card — leaving the catalog row visually
inconsistent with the eleven sibling `video-template-hyperframes-*`
plugins that have real Cloudflare-Stream poster URLs.
Drop the preview block entirely so the manifest stops promising a
demo it can't deliver. The landing-page detail row continues to
render the typographic fallback card (sourced from title /
description / mode), which is now the honest representation:
"this is an instruction skill, not a renderable template".
* fix(landing-page): address PR #2958 review feedback on plugin preview pipeline
Two blocking issues called out in code review:
1) `bundled-plugins.ts` exposed `previewEntryUrl` for every manifest
that declared `preview.type: "html"`, even when the entry file
wasn't shipped. Several first-party manifests fall in this state
(example-design-brief's `./brief-preview.html`, example-x-research,
example-pptx-html-fidelity-audit, example-hatch-pet,
example-last30days, example-guizang-ppt, example-replit-deck,
example-live-artifact, example-html-ppt, example-dcf-valuation).
The detail page then rendered a click-to-expand iframe and popout
link to a file that copy-example-html.ts had skipped, so the
iframe URL SPA-fell-back to the homepage on Cloudflare Pages.
`entryRelativeUrl()` now `existsSync()`-checks the resolved local
path before returning a URL. When the file's missing the detail
page falls through to the static thumbnail branch, exactly like
plugins that ship no preview entry at all.
2) `copy-example-html.ts` recognised only `(src|href|poster)="./assets/..."`
and then bulk-copied the entry's sibling `assets/` folder, so it
missed two real ref shapes: bare-relative (`href="assets/styles.css"`,
`src="assets/deck-stage.js"` under example-html-ppt-zhangzara-pin-and-paper)
and cross-folder (`src="../open-design-landing/assets/hero.png"`
under example-open-design-landing-deck).
Replaced the heuristic with a generic walker that:
- Parses every relative ref in the entry HTML
(`(src|href|poster|srcset|data-src)=` plus `url(...)`), splitting
srcset on whitespace/commas so multi-URL attrs are honoured.
- Resolves each ref against `dirname(entrypointSrc)` for the source
and against `dirname(iframeAbsPath)` for the destination —
identical to how a browser resolves the same ref against the
iframe URL. Files outside the source root or the iframe root
are dropped.
- Recurses into copied HTML / CSS / JS / SVG so multi-step chains
(entry → assets/template.html → assets/fonts/foo.woff) don't
strand intermediate files.
- Tracks visited *destinations* rather than sources, so a single
source that legitimately needs to land at two different out-paths
(same-folder copy at /plugins/example-X/assets/foo.png AND a
cross-folder copy at /plugins/open-design-landing/assets/foo.png
for sibling decks that use `../open-design-landing/assets/foo.png`)
gets both copies.
Verified manually:
- /plugins/example-html-ppt-zhangzara-pin-and-paper/assets/styles.css
and assets/deck-stage.js → 200 (bare-relative)
- /plugins/open-design-landing/assets/hero.png and assets/about.png
→ 200 (cross-folder destination, no manifest-id prefix because
iframe URL `..` collapses the prefix)
- /plugins/example-design-brief/ renders the static thumbnail only,
no click-to-expand iframe (broken entry guard)
- /plugins/example-flowai-live-dashboard-template/assets/template.html
→ 200 (existing same-folder behaviour preserved)
Build now reports `copied 266 entry files + 65 referenced files`,
where the 65 includes both the same-folder `./assets/...` payloads
the previous heuristic captured and the bare-relative + cross-folder
shapes it didn't.
---------
Co-authored-by: Joey-nexu <joeylee12629@gmail.com>
PR #2461 sync prep — resolves 14 conflicts merging 84 main-side commits
on top of 58 release-side commits accumulated during the 0.8.0 cycle.
Resolution summary:
Take main (theirs) where main carried deliberate forward progress:
- apps/web/src/components/PluginCard.tsx — 7 hunks, i18n migration:
hardcoded English aria-labels/titles replaced with t() calls keyed
on pluginCard.* (all 8 keys verified present in en.ts).
- apps/web/src/components/TasksView.tsx — 1 hunk, source-ingestion
feature: sortedRoutines (newest-first), sourceIngestionTemplates,
patchSourceForm, submitSourceIngestion. activeCount/pausedCount
semantics preserved (now keyed on sortedRoutines, count unchanged).
- e2e/ui/app.test.ts — new node:fs/promises + tmpdir + path + @/timeouts
imports needed by main-side test helpers.
- e2e/ui/settings-local-cli-codex-fallback.test.ts — menu-dismissal
helper block added by main.
Keep both sides where each added a different field to the same object
literal:
- apps/web/src/components/ProjectView.tsx (locale + analyticsHints
spread).
- apps/web/src/components/DesignSystemFlow.tsx (locale + analyticsHints).
Take release (ours) where release carried deliberate work that ships
0.8.0:
- CHANGELOG.md — release-side 0.8.0 entry + PR link refs; main's
Unreleased section was the same body of work, now finalized.
- apps/landing-page/public/{apple-touch-icon,favicon}.png +
apps/web/public/app-icon.svg — release-side visual refresh assets
consistent with 0.8.0 stable ship.
- tools/pack/src/linux.ts — packageVersion const required by line 466;
taking main's empty line would build-error.
- e2e/ui/project-management-flows.test.ts +
e2e/ui/settings-api-protocol.test.ts +
e2e/ui/settings-memory-routines.test.ts — release-side release-smoke
hardening (shangxinyu1 + PerishFire) takes precedence on overlap.
Closes-issue / unblocks: PR #2461 sync release/v0.8.0 → main.
* Polish design system home flows
* Polish home prompt presets
* Polish home working directory controls
* test: align home hero chrome smoke
* fix: stabilize home composer ci checks
---------
Co-authored-by: qiongyu1999 <2694684348@qq.com>
Two preview-time bugs surfaced ahead of 0.8.0:
1. Pitch-deck example (#2215): the official html-ppt-pitch-deck prompt asked
the agent to confirm three facts first, but the manifest had no
structured `od.inputs`, so the platform's required-input gate had no
fields to enforce and the run could publish HTML that still contained
unresolved fundraising placeholders (`Name to confirm`, `$X.XM`,
`Replace this panel with`, ...). Add structured required inputs to the
manifest and a daemon-side publication guard that rejects HTML/deck
artifact writes whose body still contains those placeholders. Scope is
the file-write boundary only (no assistant-text scanning), so the
guard cannot trip on the agent's chat prose mid-clarification.
2. Framework deck preview off-screen: `injectDeckBridge` injected
`place-content: center !important` on `.deck-shell` for every deck-mode
srcdoc, which forced the framework's `display: grid` shell to re-center
its implicit track. The framework's `fit()` already centers a
`transform-origin: top left` stage with an explicit `translate(tx, ty)`
that assumes the stage's natural layout position is (0, 0); the two
centerings stacked and the scaled stage landed ~1000px off-screen, so
the preview showed a sliver of slide content in the top-left with the
rest black. Skip the override when the framework's `id="deck-stage"`
marker is in the doc, and drop the dead `display: grid; place-items:
center` from the deck framework template so future drift can't
re-introduce the same stack.
* chore(featured): curate Featured picks down to top 10 across categories
The picker's Featured chip currently surfaces 64 plugins because
`isFeaturedPlugin` (apps/web/src/components/plugins-home/facets.ts)
treats any finite `od.featured` number as featured, and the field
had been adopted incrementally by 51 skills + 13 templates without
a curation step. The result is a "Featured" tab that's effectively
"everything tagged at all" — no editorial signal.
Curate down to 10 picks, allocated to keep the showcase legible:
0.001 skills/deck-swiss-international
0.01 skills/deck-guizang-editorial
0.02 design-templates/magazine-poster [add]
0.04 skills/doc-kami-parchment
0.10 design-templates/web-prototype-taste-brutalist [add od: block]
0.13 skills/video-hyperframes
0.14 skills/frame-glitch-title
0.15 skills/vfx-text-cursor
0.16 skills/frame-logo-outro
0.17 skills/deck-open-slide-canvas
Selection mirrors the html-anything `recommended: 1..10` ranking
(html-anything is the upstream content source for these skills, per
the `od.upstream` field on each SKILL.md). Two of those 10 picks
weren't in the prior featured set at all — `magazine-poster` had no
`od.featured` field and `web-prototype-taste-brutalist` had no `od:`
block at all — so they get added rather than just rebalanced.
Removes `od.featured` from the other 56 files. No UI code change;
the existing `isFeaturedPlugin` logic now reads a curated set
instead of an accidental one.
* chore(featured): align baked plugin manifests with curated top 10
The picker reads `od.featured` from each plugin's
`plugins/_official/examples/<id>/open-design.json` manifest, not from
the SKILL.md frontmatter the previous commit edited. Without this
follow-up the curated set of 10 would be invisible to users — the
picker's Featured chip would still surface 27 baked plugins from the
pre-existing manifests.
Mirror the SKILL.md curation into the baked layer:
removed `od.featured` from 19 manifests:
article-magazine, card-xiaohongshu, data-report,
frame-data-chart-nyt, frame-flowchart-sticky,
frame-light-leak-cinema, frame-liquid-bg-hero,
frame-macos-notification, guizang-ppt, html-ppt,
kami-deck, kami-landing, mockup-device-3d,
open-design-landing-deck, ppt-keynote, resume-modern,
social-reddit-card, social-spotify-card, social-x-post-card
added `od.featured` to 2 manifests:
magazine-poster -> 0.02
web-prototype-taste-brutalist -> 0.10
Verified locally against `daemon /api/plugins`: featured count is
now exactly 10, matching the SKILL.md source of truth from the
previous commit.
* feat(chat-composer): enhance mention handling and input overlay
- Introduced a new overlay for inline mentions in the chat composer, improving user experience by visually indicating mentions as users type.
- Updated the `ChatComposer` component to manage mention entities and integrate them into the input field, allowing for better context and interaction.
- Enhanced the `AssistantMessage` component to support the display of plugin action panels based on the current project context, facilitating easier plugin management.
- Refactored related components to ensure consistent handling of project files and mentions across the application.
This update significantly improves the chat interaction model, making it more intuitive for users to engage with mentions and plugins.
* feat(plugin-management): enhance plugin action panels and UI components
- Updated the `AssistantMessage` component to include plugin action panels based on the latest project context, improving user interaction with generated plugins.
- Refactored the `PluginsView` to support detailed views for available marketplace entries, allowing users to access more information and actions for each plugin.
- Introduced new CSS styles for improved visual representation of plugin-related UI elements, enhancing overall user experience.
- Enhanced the `listPlugins` function to include an option for fetching hidden plugins, providing more flexibility in plugin management.
This update significantly improves the usability and functionality of the plugin management system, making it easier for users to interact with and manage their plugins.
* fix(assistant-message): refine plugin folder candidate selection logic
- Updated the `pluginFoldersTouchedThisTurn` function to improve the logic for selecting plugin folder candidates based on touched paths and message content.
- Introduced a new helper function, `pathMatchesFolderFileBasename`, to enhance the matching criteria for folder candidates.
- Added a check for explicit folder matches before falling back to a single candidate, improving accuracy in folder selection.
- Modified the `shouldRenderSlotAsText` function in `HomeHero` to include the name parameter, refining the rendering logic for slot text.
These changes enhance the functionality and reliability of the assistant message component in managing plugin folder candidates.
* feat(plugin-folder-actions): implement agent-routed CLI actions for plugin management
- Introduced a new `PluginFolderAgentAction` type to streamline actions related to plugin folders, including install, publish, and contribute.
- Updated the `DesignFilesPanel`, `FileWorkspace`, and `AssistantMessage` components to utilize the new agent action handling, improving user interaction with generated plugins.
- Refactored the action handling logic to send commands to the agent, enhancing the workflow for managing plugin folders.
- Added corresponding tests to ensure the new functionality works as expected and integrates seamlessly with existing components.
This update significantly enhances the plugin management experience by routing actions through the agent, allowing for a more cohesive and interactive user experience.
* Fix PR 1702 CI blockers
* Fix PR 1702 remaining CI checks
* Prebuild AGUI adapter after install
* Restore plugin project snapshot wiring
* feat(marketplace): refactor marketplace URL handling and enhance fetching logic
- Introduced new functions to normalize marketplace URLs and manage fetching of marketplace manifests, improving the reliability of marketplace integrations.
- Updated the server and plugin logic to utilize the new fetching mechanisms, ensuring consistent handling of marketplace data.
- Enhanced tests to cover new URL normalization and fetching scenarios, ensuring robustness in marketplace management.
This update significantly improves the marketplace experience by streamlining URL handling and enhancing data fetching capabilities.
* Fix project auto-send cleanup spec
- Introduced a new `contextPlugins` field in the `ProjectMetadata` type to accommodate plugins selected via `@` mentions, allowing for additive context in project creation.
- Updated the `HomeHero` and `EntryShell` components to handle and display context plugins, enhancing user interaction with selected plugins.
- Implemented rendering logic for context plugins in the metadata block, providing clear visibility of selected plugins and their descriptions.
- Enhanced the UI to support the removal of context plugins and display additional details on hover, improving the overall user experience.
This update significantly enriches the project creation process by allowing users to incorporate multiple context plugins seamlessly.
- Introduced the `@open-design/registry-protocol` package, enabling improved interactions with plugin registries.
- Updated the `typecheck` script in the daemon's `package.json` to include the new registry protocol.
- Enhanced the CLI with new flags and commands for better plugin management, including `yank` and additional marketplace functionalities.
- Implemented a plugin lockfile system to manage installed plugins and their versions, improving reliability during upgrades.
- Added new marketplace doctor functionality to validate plugin entries and ensure compliance with registry standards.
This update significantly enhances the plugin ecosystem by providing robust registry interactions and improved management capabilities.
- Introduced `login` and `whoami` commands to the plugin CLI, enabling users to authenticate with the Open Design registry via GitHub CLI.
- The `login` command wraps GitHub CLI authentication, allowing users to specify a host, defaulting to GitHub.
- The `whoami` command retrieves and displays the authenticated GitHub account information, with an option for JSON output.
- Updated the CLI help documentation to include usage instructions for the new commands.
- Enhanced error handling for GitHub CLI dependencies and authentication status.
This update improves the user experience by simplifying the authentication process for plugin publishing.
- Introduced `specVersion` and `version` fields to the plugin and marketplace schemas, ensuring better versioning and compatibility tracking.
- Updated various components and functions to handle the new fields, including database migrations, plugin snapshots, and marketplace management.
- Enhanced tests to validate the presence and correctness of the new fields in plugin manifests and marketplace entries.
- Improved documentation to reflect the changes in schema requirements and provide guidance on the new versioning system.
This update strengthens the plugin ecosystem by providing clear versioning, enhancing the reliability and maintainability of plugins and marketplaces.
- Introduced `PUBLISHING-REGISTRIES.md` and its Chinese counterpart, detailing strategies for publishing plugins to skills.sh, ClawHub, and GitHub.
- Updated existing documentation to reference the new publishing guidelines, ensuring clarity on the process for external registry distribution.
- Enhanced `AGENT-DEVELOPMENT.md` and `CONTRIBUTING.md` to include notes on registry publishing, improving the overall authoring experience for plugin developers.
This update provides comprehensive guidance for plugin authors on how to effectively publish their work across various registries, enhancing the accessibility and usability of the plugin ecosystem.
- Replaced the `community/` directory with `spec/`, which now serves as the portable plugin specification and authoring kit, including documentation, templates, and examples for contributors.
- Added new files for agent development, contributing guidelines, and a comprehensive README for the plugin spec kit.
- Updated existing documentation to reflect the new structure and clarify authoring rules for plugins.
- Introduced multiple example plugins under the new `spec/examples/` directory, showcasing various use cases and workflows for plugin authors.
This update enhances the clarity and accessibility of the plugin development process, providing a robust framework for contributors and external agents.
- Updated the `sortByVisualAppeal` function to prioritize featured ranks, ensuring that curated plugins are displayed prominently.
- Added tests to verify the new sorting logic, ensuring that plugins with numeric featured ranks are sorted correctly ahead of others.
- Introduced new example templates for a magazine article layout, a Twitter share card, and a Xiaohongshu card, expanding the available options for users.
- Enhanced the overall plugin preview experience by integrating these new templates, providing users with more visually appealing and functional examples.
This update significantly improves the plugin sorting mechanism and enriches the template offerings, enhancing user engagement and experience.
- Introduced logic to assemble example slides with a companion template when the declared entry is missing, improving the user experience for plugin previews.
- Updated the server logic to handle special cases for `example-slides.html`, ensuring proper fallback to `template.html` when applicable.
- Enhanced tests to verify the new preview assembly functionality and ensure correct rendering of fallback content.
- Added new HTML and Markdown examples for various skills, including a magazine article layout and a Twitter share card, expanding the available templates for users.
This update significantly improves the plugin preview experience, providing users with more robust and visually appealing fallback options.
- Updated the plugin sharing prompts to utilize local daemon endpoints for publishing to GitHub and contributing to Open Design, streamlining the user experience.
- Refactored the `PluginsView` and `PluginShareMenu` components to support new sharing functionalities, including confirmation modals and improved link handling.
- Enhanced the CSS styles for the plugin share confirmation modal and related UI elements for better visual consistency.
- Added tests to verify the functionality of the new sharing workflows and ensure proper integration within the existing plugin management system.
This update significantly improves the plugin sharing experience, making it easier for users to publish and contribute their plugins effectively.
- Updated terminology from "Community" to "Official" across various components to reflect first-party plugin status.
- Enhanced the ChatComposer, HomeHero, and PluginsHomeSection components to improve user experience and clarity in plugin management.
- Improved CSS styles for better visual consistency and layout across plugin-related interfaces.
- Added tests to ensure proper functionality and visibility of official plugins in the UI.
This update reinforces the distinction between official and user-installed plugins, enhancing the overall user experience in plugin interactions.
- Added new flags for conversation, message, agent, and model in the CLI to support enhanced plugin sharing features.
- Introduced a new API endpoint for creating share projects for plugins, allowing users to publish to GitHub or contribute to Open Design.
- Updated the UI components to facilitate the new sharing functionalities, including prompts for user input during the sharing process.
- Enhanced the project management system to handle new plugin share actions, improving user interaction and experience.
- Added tests to ensure the reliability of the new sharing features and their integration within the existing plugin management system.
This update significantly enhances the plugin ecosystem by enabling users to share their creations more effectively and streamline collaboration.
- Added new API endpoints for publishing plugins to GitHub and contributing to Open Design, enhancing the plugin sharing capabilities.
- Introduced functions for handling plugin sharing actions, including `publishGeneratedPluginToGitHub` and `contributeGeneratedPluginToOpenDesign`.
- Updated the `DesignFilesPanel` and `FileWorkspace` components to support new sharing functionalities, allowing users to publish or contribute plugins directly from the interface.
- Enhanced the UI with new buttons for publishing and contributing plugins, improving user interaction and experience.
- Added tests to ensure the reliability of the new sharing features and their integration within the existing plugin management system.
This update significantly improves the plugin ecosystem by enabling users to share their creations with the community and streamline collaboration.
- Updated the plugin categorization system to reflect a workflow-based model, replacing the previous category bar with a curated workflow bar (From source, Generate, Export).
- Added new export scenarios for Next.js, React, and Vue, providing users with starter plugins for downstream integration.
- Enhanced the HomeView and PluginsHomeSection components to support the new categorization and improve user interaction with plugins.
- Updated tests to cover new scenarios and ensure proper functionality across the updated plugin management system.
This update significantly improves the user experience by providing clearer categorization and new tools for exporting Open Design artifacts.
- Added a new API endpoint for installing plugins from specified folder paths, improving the plugin management experience.
- Introduced functions for normalizing and validating project plugin folder paths, ensuring robust error handling.
- Implemented a registry for built-in atom workers, allowing for dynamic signal aggregation during pipeline execution.
- Enhanced the `runStageWithRegistry` function to support multiple atom workers, merging their outputs with pessimistic logic.
- Updated the UI components to display plugin folder candidates and facilitate user interactions for plugin installation.
- Added tests for the new atom worker registry and plugin folder installation features, ensuring reliability and correctness.
This update significantly enhances the plugin installation process and the overall functionality of the atom worker system, providing users with better tools for managing plugins and their interactions.
- Introduced a new `od-media-generation` scenario plugin for handling image, video, and audio projects, providing a default pipeline for media generation.
- Updated the `collectBundledScenarios` function to deduplicate scenarios and prefer canonical IDs for task kinds, improving plugin routing.
- Enhanced the `PluginsView` and `HomeHero` components to better display community and user-installed plugins, improving user experience.
- Refactored tests to accommodate the new media generation scenario and ensure proper functionality across plugin types.
This update significantly enhances the media handling capabilities and overall plugin management experience, making it easier for users to work with various media projects.
- Added support for uploading plugins via zip files and folders, improving the plugin import process.
- Introduced a new `PluginImportModal` for a streamlined user experience when importing plugins.
- Updated the `PluginsView` to include disabled states for unfinished plugin areas, enhancing clarity for users.
- Refactored various components to utilize the new `resolvePluginQueryFallback` function for improved localization handling.
- Enhanced CSS styles for better visual feedback and responsiveness in the plugin import interface.
This update significantly improves the plugin management experience, making it easier for users to import and manage plugins effectively.
- Introduced a new plugin upload mechanism with file size limits and memory storage, allowing users to upload plugins directly.
- Implemented fallback logic for plugin application, ensuring projects can be created without explicit plugin requests.
- Enhanced the UI to support plugin selection and integration, including a new `PluginsView` component for managing plugins.
- Updated various components to utilize localized text for plugin queries, improving user experience across different languages.
- Added tests for new plugin functionalities and local skill loading, ensuring reliability and correctness.
This update significantly improves the plugin management experience, providing users with better tools for plugin integration and interaction.
- Introduced comprehensive design documentation and JSON configurations for multiple design systems, including Agentic, Airtable, Ant, Apple, Application, Arc, and Artistic.
- Each design system includes detailed guidelines on visual themes, color palettes, typography, spacing, layout, components, and interaction principles.
- Enhanced the overall design framework to support diverse user interfaces and improve consistency across applications.
This update significantly enriches the design resources available for developers, enabling them to create visually cohesive and user-friendly applications.
- Replaced the legacy tabbed categorization in `PluginsHomeSection` with a tag-driven approach, allowing dynamic filtering based on plugin tags.
- Introduced a new `PluginCard` component to encapsulate the rendering of individual plugin cards, improving separation of concerns and maintainability.
- Added a `usePluginCategories` hook to manage plugin visibility and filtering logic, enhancing the overall structure and testability of the component.
- Implemented a "More" pill for overflow tags in the filter row, improving user interaction with a cleaner UI.
- Updated CSS styles to support the new layout and improve visual consistency across the plugins home section.
This update significantly enhances the user experience by providing a more flexible and intuitive way to discover and interact with plugins.
- Introduced `EntryNavRail` for a streamlined left navigation experience, featuring primary actions and a brand logo.
- Created `EntryShell` to manage the entire home view layout, integrating the centered hero, recent projects, and plugins section.
- Developed `HomeHero` for user prompt input, allowing seamless interaction with plugins and project creation.
- Replaced the previous `PluginLoopHome` with a more cohesive `HomeView` that orchestrates plugin interactions and project submissions.
- Enhanced CSS styles for improved visual consistency across the redesigned components.
This update significantly enhances the user experience by providing a more intuitive and visually appealing entry point into the application.
Plan N4 / spec §10.1 / §23.3.3.
Lands one bundled `od.kind: 'scenario'` plugin per taskKind enum
value under plugins/_official/scenarios/. The daemon's bundled
boot walker (§3.I3) already registers them via the existing
'tier/<id>' layout, so no changes to bundled.ts.
Four scenarios:
od-new-generation discovery → plan → generate → critique (devloop)
od-figma-migration extract → tokens → generate → critique (devloop)
declares od.connectors.required: [{id:'figma'}]
so the daemon auto-derives the figma-oauth
surface at apply time
od-code-migration import → tokens → plan
→ verify (patch-edit ↔ build-test devloop, until
'build.passing && tests.passing || iterations>=8')
→ review → handoff
od-tune-collab direction → patch → critique (devloop) → handoff
Locks the spec §23.3.3 patch 3 contract: 'no od.pipeline + has
taskKind → look up the bundled scenario plugin'. The daemon-side
resolver wiring is the next PR; the substrate is in place so a
plugin author who omits the pipeline gets a deterministic default.
Daemon tests: 1543 → 1548 (+5 cases on
plugins-bundled-scenarios-roster: roster shape + per-scenario
taskKind / kind / pipeline-stage-id assertions). The atom roster
test from §3.M3+M4 stays focused on plugins/_official/atoms/.
Co-authored-by: Tom Huang <1043269994@qq.com>
Plan M3 + M4 / spec §21.4 / §23.3.2.
Lands the prompt-fragment substrate for every atom spec §10
reserves under (planned) ids. The directory now ships nine new
atom plugins under plugins/_official/atoms/, each a SKILL.md +
open-design.json pair the daemon's bundled boot walker registers
on startup:
Phase 6 (figma-migration native):
figma-extract pull node tree + tokens + assets into project cwd
token-map crosswalk source tokens onto active DESIGN.md
Phase 7 (code-migration native):
code-import normalise repo into code/index.json snapshot
design-extract lift tokens out of source / Figma / screenshots
rewrite-plan author the multi-file plan with ownership tiers
patch-edit execute one plan step per turn with ownership guards
diff-review surface unified diff + capture accept/reject
build-test run framework-default test commands; emit
build.passing + tests.passing signals
Phase 8 (production code delivery):
handoff push artifact to cli/desktop/web/docker/github/
figma/code-agent surfaces; append to
ArtifactManifest.exportTargets[]
The implementations stay deliberately prose-only in v1 — the
fragments teach the agent what each atom expects, the spec §22.5
promotion path covers iterating each one out-of-tree first. The
matching FIRST_PARTY_ATOMS catalog rows already mark them
'planned'; today's commit gives the bundled boot walker something
to register so a plugin author who references one of these ids in
od.pipeline.stages[*].atoms[] sees the SKILL.md inside the
container without the doctor warning.
apps/daemon/tests/plugins-bundled-atoms-roster.test.ts (2 cases)
pins the on-disk inventory so a future PR can't drop or rename an
atom folder without touching the spec §10 / §21 / §23 tables in
the same patch.
Daemon tests: 1519 → 1521 (+2 cases on the new roster suite).
Co-authored-by: Tom Huang <1043269994@qq.com>
Plan I3 / spec §23.3.5 + §23.3.4.
Lays the entry slice for spec §23 self-bootstrapping: the daemon's
own behavioural content moves out of system.ts hard-coded constants
and into per-atom SKILL.md files under plugins/_official/atoms/.
New ground:
- plugins/_official/atoms/ ships four canonical atom SKILL.md +
open-design.json pairs (discovery-question-form, todo-write,
direction-picker, critique-theater). Each pair is a fully valid
plugin that the existing local-folder installer can pick up; the
manifest declares od.kind='atom' so the future doctor warns when a
pipeline references the matching id but the bundled folder is
missing.
- apps/daemon/src/plugins/bundled.ts owns the boot walker:
registerBundledPlugins({ db, bundledRoot }) walks one level of
subdirectories (atoms/, scenarios/, bundles/) plus direct
plugins, registers every match into installed_plugins under
source_kind='bundled' / trust='bundled', and is idempotent across
daemon restarts (upserts on every boot).
- defaultBundledRoot(workspaceRoot) returns
<workspaceRoot>/plugins/_official; server.ts boot calls
registerBundledPlugins(..., defaultBundledRoot(PROJECT_ROOT)) and
prints a one-line summary. ENOENT is silent — running the daemon
outside the dev tree just skips this step.
The full §23 lift (system.ts prompt fragments → SKILL.md bodies +
plugin.kind='atom' → composeSystemPrompt resolving each stage's
atoms[] through the registry) stays open. This commit is the
substrate slice: bundled plugins are now first-class
installed_plugins rows under the new tier, doctor / list / info /
apply all pick them up, and a future PR that wires composeSystemPrompt
to read SKILL.md bodies has zero registration work to do.
Daemon tests: 1476 → 1481 (+5 cases on plugins-bundled covering
tiered + direct layouts, idempotent reruns, ENOENT, miss-skips).
Co-authored-by: Tom Huang <1043269994@qq.com>
