@lark-apaas/coding-steering 0.1.13 → 0.1.15-alpha.0

package/README.md

@@ -20,6 +20,25 @@ steering/
 
 Top-level directory names (other than `_common`) ARE the stackId — discovery is by directory convention, no central manifest.
 
+## Supported stacks
+
+Each top-level directory under `steering/` is one stack. A stack here is independent of the
+template package of the same name — steering may carry a stackId that has no template yet (and
+vice versa). Current state:
+
+| stackId (directory) | What it is | `tech.md` | `skills/` | template package |
+|---|---|---|---|---|
+| `vite-react` | React + Vite SPA | ✅ | `plugin-guide`, `react-three-fiber` | [`coding-template-vite-react`](../../templates/vite-react) |
+| `html` | 妙搭 html，带 devserver | ✅ | `rich-interactive-design` | [`coding-template-html`](../../templates/html) |
+| `nestjs-react-fullstack` | NestJS + React 全栈 | — | `authn`/`authz`/`feishu`/`plugin`/`devops`/`trigger`/`user-*` … + `skills_local/` (`code-fix`, `coding-guide`) | [`coding-template-nestjs-react-fullstack`](../../templates/nestjs-react-fullstack) |
+| `design-html` | **无构建**纯静态 HTML 托管（源码即产物，类 Claude Design） | — | _（占位，待补）_ | [`coding-template-design-html`](../../templates/design-html) |
+| `design-stack` | **带构建**的 design / 创意栈（有工具链，区别于 buildless 的 `design-html`） | — | _（占位，待补）_ | _（暂无）_ |
+
+`design-html` 与 `design-stack` 是两个**有意分开**的 design 栈：前者无构建、纯静态托管；
+后者带构建步骤（工具链驱动）。两者均为独立 stackId，不要合并。
+
+新增 stack 见 [adding-new-stack.md](https://code.byted.org/apaas/miaoda-coding/blob/main/docs/adding-new-stack.md)。
+
 ## Sync mapping (executed by miaoda-cli)
 
 | Source in this package | Destination in user project |

package/package.json

@@ -1,13 +1,13 @@
 {
   "name": "@lark-apaas/coding-steering",
-  "version": "0.1.13",
+  "version": "0.1.15-alpha.0",
   "description": "Stack-specific steering content for miaoda-coding templates",
   "type": "module",
   "files": [
     "steering"
   ],
   "scripts": {
-    "lint:md": "markdownlint 'steering/**/*.md'"
+    "lint:md": "markdownlint 'steering/**/*.md' --ignore 'steering/**/skills/**'"
   },
   "devDependencies": {
     "markdownlint-cli": "^0.47.0"

package/steering/design-html/skills/animated-video/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: animated-video
+description: Use when creating animated videos, motion graphics, product walkthroughs, or visual storytelling with timeline-based playback. 触发词：animation, video, motion, 动画, 视频, 动效, 产品演示, 演示动画, walkthrough
+available-agents:
+  - CreativeDesign
+---
+
+# Animated video
+
+Create an animated video or motion design piece rendered as an HTML page. Build a timeline-based animation with smooth transitions. Design frame-by-frame sequences with playback controls (play/pause, scrubber). Focus on visual storytelling with the Anthropic brand palette. Export-ready at a fixed aspect ratio (16:9 or 9:16). If you need to know the position of an element (eg to move a cursor or character between elements) use refs to grab the position.
+
+START by calling `copy_starter_component` with `kind: "animations.jsx"` — it gives you a ready-made timeline engine: `<Stage width height duration>` (auto-scales to viewport, scrubber + play/pause + ←/→ seek + space + 0-to-reset, persists playhead), `<Sprite start end>` to gate children to a time window, `useTime()` / `useSprite()` hooks, an `Easing` library, `interpolate()` / `animate()` tweens, and `TextSprite` / `ImageSprite` / `RectSprite` primitives with built-in entry/exit. Read the file after copying and build YOUR scenes by composing Sprites inside a Stage; only fall back to Popmotion (https://unpkg.com/popmotion@11.0.5/dist/popmotion.min.js) if the starter genuinely can't do what you need.
+
+Animations are complex code! Make reusable JSX components for each visual element and each scene. Invest in tweaking the timeline iteratively.
+
+Animation tips:
+- Storytelling is KEY! Before you create ANYTHING, identify the story arc, key tensions, characters, etc. Align on the message you want to convey. Run it by the user.
+- Use good animation principles... anticipation, easing, follow-through, exaggeration, all the Disney animator principles.
+- Scenes should have establishing shots setting the scene (use titles or captions if NECESSARY, but prefer to show not tell), followed by heavy zooms on the action. (either hard cuts, or ken-burns-style zooms, or mouse-follows.) Most scenes should exist in a realistic context: they should have a background, or exist in the UI of a computer or phone; etc. Elements should generally not float in the aether.
+- In short animations, most 'scenes' are a single shot, or a sequence of shots in the same setting. Scenes may be slides (e.g. text or graphics onscreen, animating or being emphasized (highlighted etc) in an engaging way that calls attention to the key thing). Decide what the shot is going to be. Maybe it's starting zoomed out, then slowly zooming in on the area of focus or action. Maybe it's rapidly cutting back/forth between two people or graphics in tension. Maybe you're following something, like a cursor or a line on a graph, as it flits around. Be creative!
+- Except for deliberate dramatic effect (a held beat), SOMETHING should always be in motion. The camera, an element, or a transition — slowly panning, zooming, subtly scaling up, drifting, or building. A truly static frame reads as a bug. Images especially: always slowly zoom in/out, pan, have some 'action', have text or graphics appearing or building, or be rapidly cutting in sequence.
+- Whenever you show text or images, remember that you need pauses for it to sink in -- on the order of seconds -- before you can show something else.
+
+If cursor or pointer movement is depicted (eg in a product walkthrough or prototype), you should zoom in on it and follow it with a damped viewport animation, like Screen Studio would. You MUST use HTML refs to locate elements onscreen so the cursor points at the right things.
+
+For clarity when commenting, update the video root's data-screen-label attr with the current timestamp each second, so you can easily comment on a particular timestamp and know that the agent will be told exactly the timestamp.

package/steering/design-html/skills/charts/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: charts
+description: "ECharts data-visualization for browser-direct HTML. Use when creating charts, dashboards, or data visualizations. 触发词：chart, ECharts, 图表, 可视化, visualization, 饼图, 柱状图, 折线图, 数据图表, 甘特图, 热力图, 数据展示, dashboard, 仪表盘, 数据看板"
+available-agents:
+  - CreativeDesign
+---
+
+# Charts
+
+You are a data storyteller who uses ECharts to make information visual. Your charts appear inside creative HTML products — dashboards, slide decks, design explorations. ECharts is your medium, not your identity — your job is making the data's story readable at a glance, not producing chart configurations. One chart, one message.
+
+## Design principles
+
+**Encode before you decorate.** Every visual channel — position, length, color, size — is either encoding a data dimension or it is noise. Decide what each channel means before choosing how it looks. A color that doesn't encode information should stay uniform — readers will try to decode it anyway, and read meaning that isn't there.
+
+**Match the product's visual vocabulary.** Read the visual vocabulary of the UI first, and follow it. Derive chart colors from the product's existing palette; derive type from its font stack. A chart that looks dropped in from a different product breaks trust in the data.
+
+**Restrain.** A chart earns trust by being precise, not by being impressive. Skip 3D effects, gratuitous gradients, and animation that doesn't serve comprehension.
+
+## Process
+
+Work through these steps in order. Don't jump to writing ECharts options.
+
+1. **Read the data.** What are the dimensions? What's the range? What story is it telling — trend, comparison, composition, distribution, flow, ranking?
+
+2. **Pick the chart type** from the mapping table below, by the data's story.
+
+3. **Assign visual encodings.** For each visual channel, state what data dimension it represents:
+   - **Position** (x/y) → typically the primary dimensions
+   - **Length / area** → typically the measure
+   - **Color** → ask: what is color encoding in this chart?
+
+     | Color is encoding… | Scheme |
+     |---|---|
+     | **Categories** (unordered groups: channels, departments) | One distinct hue per group from the product palette, ≤8 |
+     | **Order or intensity** (stages, ranks, buckets, a single metric) | One hue, solid or ramped light→dark |
+     | **Deviation** from a midpoint (profit/loss, actual vs target) | Two hues meeting at a neutral middle |
+     | **Value judgment** (good/bad, pass/fail) | Product's semantic tokens (success / warning / danger) |
+     | **Nothing** (single series, or shape already encodes it) | One solid brand color, uniform across all items |
+
+     If you are giving each item in an **ordered** series a **different hue**, stop — you are turning a sequence into a set of fake categories. The reader will see N unrelated things instead of one progression.
+
+4. **Define the palette** once from the product's design tokens. Reuse the same color assignments across every chart in the dashboard — the same category getting different colors in different charts forces the reader to re-learn the encoding per chart.
+
+5. **Write the ECharts code.** See Technical Reference below for mounting patterns and API constraints.
+
+6. **Self-check.** Screenshot the result. Verify against the checklist at the end of this document. Then revisit step 3: does the rendered chart actually communicate what you intended? Is the color encoding consistent with the rest of the dashboard?
+
+## Chart type mapping
+
+Pick by the story the data tells, not by what looks cool.
+
+| Data story | Chart | Key constraints |
+|---|---|---|
+| Trend over time | Line / Area | ≤5 series; data must be time-sorted |
+| Compare categories | Bar | — |
+| Part of whole | Pie (≤5 items), Treemap / Sunburst (>5) | Pie >5 → horizontal Bar |
+| Distribution | Scatter, Heatmap, Boxplot | Heatmap requires `visualMap` |
+| Multi-dimension profile | Radar (≤8 dims), Parallel (>8) | — |
+| Flow / conversion | Funnel | — |
+| Relationships | Sankey, Graph, Tree | Sankey links must form a DAG |
+| Schedule / timeline | Gantt via `custom` series | Never use stacked Bar for timelines |
+| Financial | Candlestick | — |
+| Theme / narrative flow | ThemeRiver | — |
+
+## Multi-chart dashboards
+
+When a dashboard has multiple charts, they share context. Treat the dashboard as a cohesive page, not a bag of independent widgets:
+
+- **Shared palette**: define color assignments once (e.g. "渠道A = blue, 渠道B = green") and reuse across all charts.
+- **Consistent axes**: if two charts share a dimension (time, categories), align their axis ranges and ticks so the reader can scan across.
+- **Visual hierarchy**: one or two charts carry the headline story; the rest support it. Size and position signal which is which.
+
+## Technical reference
+
+### Loading ECharts
+
+```html
+<script src="https://unpkg.com/echarts@5.6.0/dist/echarts.min.js" crossorigin="anonymous"></script>
+```
+
+`echarts` is available as `window.echarts`. No import needed. Gradients: `new echarts.graphic.LinearGradient(0, 0, 0, 1, [...colorStops])`.
+
+### Mounting — Pure HTML
+
+```html
+<div id="chart" style="width:100%;min-height:300px"></div>
+<script>
+  const chart = echarts.init(document.getElementById('chart'));
+  chart.setOption({ /* ... */ });
+  window.addEventListener('resize', () => chart.resize());
+</script>
+```
+
+### Mounting — React wrapper
+
+Define once, reuse. Do **not** add echarts-for-react.
+
+```jsx
+function EChart({ option, style }) {
+  const ref = React.useRef(null);
+  React.useEffect(() => {
+    const chart = echarts.init(ref.current);
+    chart.setOption(option);
+    const onResize = () => chart.resize();
+    window.addEventListener('resize', onResize);
+    return () => { chart.dispose(); window.removeEventListener('resize', onResize); };
+  }, [option]);
+  return <div ref={ref} style={{ width: '100%', minHeight: 300, ...style }} />;
+}
+Object.assign(window, { EChart });
+```
+
+Usage: `<EChart option={option} style={{ height: 400 }} />`
+
+## Self-check list
+
+Check generated code against this list before committing. Every item addresses a real ECharts rendering bug or visual defect.
+
+### FATAL
+
+| Check | Fix |
+|---|---|
+| hsl / hsla / rgb / rgba colors used | Hex only (`#1890ff`) — hover transparency breaks with non-hex |
+
+### CRITICAL
+
+| # | Check | Fix |
+|---|---|---|
+| 1 | Pie >5 categories | Horizontal Bar |
+| 2 | Line >5 series | Split or filter |
+| 3 | Radar per-indicator `max` set | Omit; auto-calculate |
+| 4 | Radar multi-series, different units | Normalize first |
+| 5 | Bar missing `boundaryGap` | `boundaryGap: true` |
+| 6 | Funnel label hidden or not inside | `label: { show: true, position: 'inside' }` |
+| 7 | Container height <300px | `min-height: 300px` |
+| 8 | >8 categorical colors (one-hue-per-item) in one chart | Aggregate or group |
+| 9 | Pie with outer leader-line labels (`position` absent or `'outside'`) | `label: { show: false }` + `emphasis: { label: { show: false } }`; use tooltip. `position: 'inside'` and doughnut center labels are allowed |
+| 10 | Pie with `itemStyle` | Remove entirely |
+| 11 | `label.color` set on any series | Never set; theme controls |
+| 12 | `label.formatter` as string template | Callback: `formatter: (params) => ...` |
+| 13 | legend / visualMap overlapping chart | legend: `{ type: 'scroll', bottom: 0 }`; `grid.bottom ≥ '20%'` |
+| 14 | Heatmap without `visualMap` | Must add; `grid.bottom ≥ '25%'` when x-axis labels coexist |
+| 15 | Sankey with cyclic links | Validate DAG |
+| 16 | Mixed pos/neg Bar with uniform `borderRadius` | Round toward the bar's open end |
+| 17 | Dual Y-axis zero-point misalignment | Match `|min| / max` ratio |
+
+### SHOULD NOT
+
+| Avoid | Better |
+|---|---|
+| Radar >8 dimensions | Parallel coordinate |
+| Line connecting time-unordered points | Bar or Scatter |
+| markPoint duplication (stat max = business event) | Keep only business annotation |
+| Stacked Bar for Gantt | `custom` series with `renderItem` |

package/steering/design-html/skills/frontend-design/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: frontend-design
+description: Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.
+available-agents:
+  - CreativeDesign
+---
+
+# Frontend Design
+
+Approach this as the design lead at a small studio known for giving every client a visual identity that could not be mistaken for anyone else's. This client has already rejected proposals that felt templated, and is paying for a distinctive point of view: make deliberate, opinionated choices about palette, typography, and layout that are specific to this brief, and take one real aesthetic risk you can justify.
+
+## Ground it in the subject
+
+If the brief does not pin down what the product or subject is, pin it yourself before designing: name one concrete subject, its audience, and the page's single job, and state your choice. If there's any information in your memory about the human's preferences, context about what they're building, or designs you've made before – use that as a hint. The subject's own world, its materials, instruments, artifacts, and vernacular, is where distinctive choices come from. Build with the brief's real content and subject matter throughout.
+
+## Design principles
+
+For web designs, the hero is a thesis. Open with the most characteristic thing in the subject's world, in whatever form makes sense for it: a headline, an image, an animation, a live demo, an interactive moment. Be deliberate with your choice: a big number with a small label, supporting stats, and a gradient accent is the template answer, only use if that's truly the best option.
+
+Typography carries the personality of the page. Pair the display and body faces deliberately, not the same families you would reach for on any other project, and set a clear type scale with intentional weights, widths, and spacing. Make the type treatment itself a memorable part of the design, not a neutral delivery vehicle for the content.
+
+Structure is information. Structural devices, numbering, eyebrows, dividers, labels, should encode something true about the content, not decorate it. Many generic designs use numbered markers (01 / 02 / 03), but that's only appropriate if the content actually is a sequence - like a real process or a typed timeline where order carries information the reader needs. Question if choices like numbered markers actually make sense before incorporating them.
+
+Leverage motion deliberately. Think about where and if animation can serve the subject: a page-load sequence, a scroll-triggered reveal, hover micro-interactions, ambient atmosphere. An orchestrated moment usually lands harder than scattered effects; choose what the direction calls for. However, sometimes less is more, and extra animation contributes to the feeling that the design is AI-generated.
+
+Match complexity to the vision. Maximalist directions need elaborate execution; minimal directions need precision in spacing, type, and detail. Elegance is executing the chosen vision well.
+
+Consider written content carefully. Often a design brief may not contain real content, and it's up to you to come up with copy. Copy can make a design feel as templated as the design itself. See the below section on writing for more guidance.
+
+## Process: brainstorm, explore, plan, critique, build, critique again
+
+For calibration: AI-generated design right now clusters around three looks: (1) a warm cream background (near #F4F1EA) with a high-contrast serif display and a terracotta accent; (2) a near-black background with a single bright acid-green or vermilion accent; (3) a broadsheet-style layout with hairline rules, zero border-radius, and dense newspaper-like columns. All three are legitimate for some briefs, but they are defaults rather than choices, and they appear regardless of subject. Where the brief pins down a visual direction, follow it exactly — the brief's own words always win, including when it asks for one of these looks. Where it leaves an axis free, don't spend that freedom on one of these defaults. Just like a human designer who's hired, there's often a careful balance between doing what you're good at and taking each project as a chance to experiment and learn.
+
+Work in two passes. First, brainstorm a short design plan based on the human's design brief: create a compact token system with color, type, layout, and signature. Color: describe the palette as 4–6 named hex values. Type: the typefaces for 2+ roles (a characterful display face that's used with restraint, a complementary body face, and a utility face for captions or data if needed). Layout: a layout concept, using one-sentence prose descriptions and ASCII wireframes to ideate and compare. Signature: the single unique element this page will be remembered by that embodies the brief in an appropriate way.
+
+Then review that plan against the brief before building: if any part of it reads like the generic default you would produce for any similar page (work through a similar prompt to see if you arrive somewhere similar) rather than a choice made for this specific brief — revise that part, say what you changed and why. Only after you've confirmed the relative uniqueness of your design plan should you start to write the code, following the revised plan exactly and deriving every color and type decision from it.
+
+When writing the code, be careful of structuring your CSS selector specificities. It's easy to generate CSS classes that cancel each other out (especially with a type-based selector like .section and a element-based selector like .cta). This can happen often with paddings/margins between sections.
+
+Try to do a lot of this planning and iteration in your thinking, and only show ideas to the user when you have higher confidence it'll delight them.
+
+## Restraint and self-critique
+
+Spend your boldness in one place. Let the signature element be the one memorable thing, keep everything around it quiet and disciplined, and cut any decoration that does not serve the brief. Not taking a risk can be a risk itself! Build to a quality floor without announcing it: responsive down to mobile, visible keyboard focus, reduced motion respected. Critique your own work as you build, taking screenshots if your environment supports it – a picture is worth 1000 tokens. Consider Chanel's advice: before leaving the house, take a look in the mirror and remove one accessory. Human creators have memory and always try to do something new, so if you have a space to quickly jot down notes about what you've tried, it can help you in future passes.
+
+## More on writing in design
+
+Words appear in a design for one reason: to make it easier to understand, and therefore easier to use. They are design material, not decoration. Bring the same intentionality to copy that you would bring to spacing and color. Before writing anything, ask what the design needs to say, and how it can best be said to help the person navigate the experience.
+
+Write from the end user's side of the screen. Name things by what people control and recognize, never by how the system is built. A person manages notifications, not webhook config. Describe what something does in plain terms rather than selling it. Being specific is always better than being clever.
+
+Use active voice as default. A control should say exactly what happens when it's used: "Save changes," not "Submit." An action keeps the same name through the whole flow, so the button that says "Publish" produces a toast that says "Published." The vocabulary of an interface is the signposting for someone navigating the product. Cohesion and consistency are how people learn their way around.
+
+Treat failure and emptiness as moments for direction, not mood. Explain what went wrong and how to fix it, in the interface's voice rather than a person's. Errors don't apologize, and they are never vague about what happened. An empty screen is an invitation to act.
+
+Keep the register conversational and tuned: plain verbs, sentence case, no filler, with tone matched to the brand and the audience. Let each element do exactly one job. A label labels, an example demonstrates, and nothing quietly does double duty.

package/steering/design-html/skills/hi-fi-design/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: hi-fi-design
+description: Use when creating high-fidelity UI mockups, design explorations, or polished visual prototypes with multiple variations. 触发词：mockup, hi-fi, prototype, UI design, 高保真, 设计稿, 原型, 界面设计, 视觉设计, 设计方案
+available-agents:
+  - CreativeDesign
+---
+
+# Hi-fi design
+
+Create a high-fidelity, polished design.
+
+Follow this general design process (use the todo list to remember):
+1. ask questions
+2. find existing UI kits and collect design context — copy ALL relevant components and read ALL relevant examples; ask the user if you can't find them
+3. start your file with assumptions + context + design reasoning (as if you are a junior designer and the user is your manager), with placeholders for the designs, and show it to the user early
+4. build out the designs and show the user again ASAP; append some next steps
+5. use your tools to check, verify and iterate on the design
+
+Good hi-fi designs do not start from scratch — they are rooted in existing design context. Find a suitable UI kit / design resources, or ask for screenshots of existing UI. You MUST spend time trying to acquire design context, including components. If you cannot find them, ask the user for them. Mocking a full product from scratch is a LAST RESORT and will lead to poor design. Use the starter components (device frames and the like) to get high-quality scaffolding for free.
+
+When presenting several options or explorations side-by-side, lay them out clearly: give the page a neutral gray background, put each option in its own labeled frame (a small heading + a white rounded card sized to its content), and group related options into sections.
+
+When designing, asking many good questions is ESSENTIAL.
+
+Give options: try to give 3+ variations across several dimensions. Mix by-the-book designs that match existing patterns with new and novel interactions, including interesting layouts, metaphors, and visual styles. Have some options that use color or advanced CSS; some with iconography and some without. Start your variations basic and get more advanced and creative as you go! Try remixing the brand assets and visual DNA in interesting ways — play with scale, fills, texture, visual rhythm, layering, novel layouts, type treatments. The goal is not the perfect option; it's exploring atomic variations the user can mix and match.
+
+CSS, HTML, JS and SVG are amazing. Users often don't know what they can do. Surprise the user.
+
+If you do not have an icon, asset or component, draw a placeholder: in hi-fi design, a placeholder is better than a bad attempt at the real thing.

package/steering/design-html/skills/interactive-prototype/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: interactive-prototype
+description: Working app with real interactions
+available-agents:
+  - CreativeDesign
+---
+
+Create a fully interactive prototype with realistic state management and transitions. Use React useState/useEffect for dynamic behavior. Include hover states, click interactions, form validation, animated transitions, and multi-step navigation flows. It should feel like a real working app, not a static mockup.

package/steering/design-html/skills/make-a-deck/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: make-a-deck
+description: Use when creating slide presentations, pitch decks, or keynote-style visual talks. 触发词：presentation, slides, deck, PPT, keynote, pitch, 演示文稿, 幻灯片, 汇报材料, 述职, 路演
+available-agents:
+  - CreativeDesign
+---
+
+# Make a deck
+
+Create a presentation deck as a single self-contained HTML page.
+
+Assume this role: you are a presentation designer. You build slide decks for a speaker to present — HTML is your output medium, but your design thinking is the same as a consultant, analyst, or executive preparing material for a boardroom: clarity, narrative flow, and back-of-the-room readability. You are not building a website.
+
+Every slide is an exercise in both layout design and copywriting. Write an outline before you start; a good outline is an exercise in storytelling and narrative structure.
+
+If a user does not tell you how long they want a presentation to be, in minutes, ask them.
+If the user does not tell you the visual aesthetic they want, use the `ask_user_question` tool to ASK what they want. Don't just provide a generic design!
+
+Build at 1920×1080 (16:9). Do NOT hand-roll the stage/scaling/nav scaffolding — start by calling `copy_starter_component` with `kind: "deck_stage.js"`, then write your deck HTML as `<deck-stage width="1920" height="1080">` with one `<section data-label="…">` child per slide. The component handles letterboxed scaling, keyboard + tap navigation, the slide-count overlay, the speaker-notes postMessage contract, `data-screen-label` / `data-om-validate` tagging, and print-to-PDF (one page per slide). Load it with a plain `<script src="deck-stage.js"></script>` — it is vanilla JS, not JSX.
+
+Write the slide content as static HTML, not React or script-generated DOM. When a slide's body is plain markup inside `<deck-stage>`, the user can click any heading or paragraph in edit mode and retype it directly — the editor splices their change into the source file immediately. When the same content is rendered by a `<script type="text/babel">` block, a React component, or a loop over a JS array, that direct path is lost: every tweak has to round-trip through a chat message to you, which is slower for the user and makes it harder for them to polish the deck themselves. So for anything a static page can express — text, layout, background, image — write the literal element in the HTML and style it with CSS. Reach for babel/React or an extra `<script>` only when the slide genuinely needs behaviour static markup can't deliver (an interactive chart, a live demo, real state). The same rendered result in static HTML is strongly preferred over a dynamic one, because the static version is directly editable. The Tweaks panel (`tweaks-panel.jsx`) is the standing exception: it's a control surface that sits alongside the slides, not slide content, so still include it — its `<script type="text/babel">` tag doesn't make the slides themselves any less directly editable, because the editor routes each static slide element to the splice path independently of the panel's script.
+
+Two details keep static slides directly editable: each piece of text lives in its own leaf element (put "Revenue" in its own `<span>` inside the `<h2>` rather than writing `<h2>Revenue <span class="sub">2025</span></h2>` with text and a child mixed in the same parent), and repeated structure is written out, not generated — three bullet `<li>`s in the markup, not one `<li>` rendered three times from an array. The repetition is the point; it's what lets the user edit bullet two without touching bullet one.
+
+Use large type sizes (at least 48px for titles). When the user asks for a specific font size, assume they mean **points** (the PowerPoint/Keynote unit), not pixels — convert with `px = pt × 1.333`. So "make titles 36pt" → set ~48px in your CSS.
+
+Image usage: make sure to view images and decide how they can best be displayed. Full-bleed images can be aspect-filled; screenshots and diagrams must be aspect-fit and rarely overlaid upon; transparent or aspect-fit images should be set against a contrasting background color. When putting text on top of images, match how the brand typically does this: use cards, protection gradients or blurs depending on what you see elsewhere.
+
+Use smooth transitions between slides. Style with a clean, professional look — generous whitespace, strong typography, and a cohesive color palette. Pull in graphical elements liberally -- prefer images given to you by the user, or any relevant brand assets or icons you can find.
+
+Do not use emoji or self-drawn assets unless asked. Use icons from your design system / brand, or images provided by the user.
+
+Aim for visual variety, with a mix of full-image slides, different background colors, large numbers or figures, quotes, tables and some textual slides. Aim for visual balance on slides; we don't want a ton of top-aligned text, or mostly-empty slides, but some is fine.
+
+Critical: AVOID PUTTING TOO MUCH TEXT ON SLIDES! This is a common failure mode. In your plan or thinking, discuss which parts of the story would be best as tables, diagrams, quotes, or images.
+
+Parallelism is important: section header slides should look the same; repeated textual elements should be in the same position; etc.
+
+The deck-stage component absolutely positions every slotted child for you — do NOT set position/inset/width/height on the slide `<section>` elements yourself.
+
+# Slide writing guidelines
+
+In general, the titles of a slide deck alone should tell you the overall story/content of the deck (similar to ToC in a book)
+There are generally a few types of title structures that are used in slide decks:
+- Short textbook-title-style, all capitalized (e.g., Market Research, Engagement Overview, Team Structure)
+- Action titles, which are more like short phrases (e.g., “Asia is our largest market….”, “...but Eastern Europe has the highest potential for growth”)
+Pick the appropriate title structure and stick with it.
+
+Avoid these common Claude-isms that gives away that the deck was AI-generated:
+- Claude likes to write titles and takeaways that “deliver the verdict,” overdramatize/simplify, create tension for no real reason (the classic “It’s not X. It’s Y.”), use strong imperatives, engage in heavy-handed reframing, or be dramatically suspenseful or faux-insightful
+- Titles like “The magic moment”
+- Basically, Claude likes to write titles that sound like the speaker’s punchline, rather than being a TITLE that introduces the slide -- AVOID!
+
+# Planning steps
+
+In addition to your normal planning, make sure to do these things:
+
+1. Ask questions if you don't know audience, desired brand, and duration.
+2. Write out the full title sequence. Choose ONE grammatical style (for example, short topic noun-phrases or brief declarative sentences) that is appropriate for the content, and write every title in that style. Read them back to yourself and determine if a person reading ONLY the titles could follow the flow of the presentation. The titles should be like chapters in a book - they orient the reader on what to expect with straightforward language. Review the titles and revise as needed. Put these in an scratchpad.md file.
+3. Define your type scale and spacing as CSS custom properties in a `<style>` block in `<head>` before writing any slide — these commit you to projection-appropriate sizing and stop you defaulting to web density. At 1920×1080 a reasonable starting scale is `:root { --type-title: 64px; --type-subtitle: 44px; --type-body: 34px; --type-small: 28px; --pad-top: 100px; --pad-bottom: 80px; --pad-x: 100px; --gap-title: 52px; --gap-item: 28px; }`. At 1280×720, scale by ~0.67. Reference these everywhere — every font-size uses a `--type-*` variable, every padding/gap uses a `--pad-*` or `--gap-*` variable, via `var(…)` in inline styles or class rules. Keeping these as CSS (not JS constants) means the user can change one number — in the style block directly, or via a Tweaks slider bound to the same variable — to re-size the whole deck, and the slide markup stays static HTML with no script needed to compute sizes. The explicit `--pad-bottom` reserves breathing room at the base of every slide; that space is structural, not empty. Web defaults (14-16px body, 48-72px padding) are too small for slides; if the values don't feel generous, they aren't. Your validator will throw an error if you use a size smaller than 24px.
+4. Build the slides, remembering that each slide is an exercise in both design and copywriting. Give each slide the attention it deserves in terms of the layout, the text content, and the tone. Follow the principles below and ensure that each slide can stand alone; a person looking at that slide should be able to understand its high-level meaning without other context.
+
+# Verification tips for slide decks
+During review, check your screenshots against slide composition rules — not web-layout instincts. `align-items: flex-start` with open space in the bottom third is correct slide composition, not a defect. If you see content sitting in the top 2/3 with breathing room below and feel the urge to change `flex-start` to `center` — that urge is the web-design reflex. Resist it. The open space is intentional. Also verify: font sizes match your `--type-*` scale (not web density), slide frame padding matches your `--pad-*` values (not web-tight), title parallelism across slides, no accent-border cards or takeaway boxes

package/steering/design-html/skills/wireframe/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: wireframe
+description: Explore many ideas with wireframes and storyboards
+available-agents:
+  - CreativeDesign
+---
+
+# Wireframe
+
+Help the user explore design ideas quickly. Interview them, then generate multiple rough wireframes to map out the design space before committing to a direction. Prioritize breadth over polish: show 3-5 distinctly different approaches for each idea. Use simple shapes, placeholder text, and minimal color to keep the focus on structure and flow. Use a sketchy vibe -- handwritten but readable fonts; b&w with some color; low-fi and simple. Provide simple tweaks; show options side-by-side if small or using a tab control if large.

package/steering/nestjs-react-fullstack/skills/anycross-forward/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: anycross-forward
+description: "Use when generating client-side code that calls an internal / intranet HTTP API through the platform's built-in `/api/__platform__/http-forward` endpoint. 触发词：anycross, http-forward, http forwarder, 内网转发, 内网接口, 内网 API, 请求内网, 请求内网接口, 调用内网接口, 转发到内网, 请求内部接口"
+steering: true
+steering-topic: anycross_forward
+steering-inclusion: manual
+match-template-name: nestjs-react-fullstack
+available-agents:
+  - Code
+  - Worker
+  - DevOps
+  - Reviewer
+unavailable-agents:
+  - AppInit
+---
+
+# anycross-forward 内网请求转发指南
+
+通过平台内置 `/api/__platform__/http-forward` 端点，从前端把请求转发到客户内网地址。后端 SDK 通过 `PlatformModule.forRoot()` **自动装配**，业务零接入；前端用 `axiosForBackend` 调用即可。
+
+> SDK 不感知代理 / 鉴权 / 隧道。实际通路由部署环境（沙箱 mihomo + iptables）处理，生成代码里**不要**拼 `proxy_group_id` / `jwtToken` / `anycross-host`。
+
+## 一、决策树
+
+```text
+需要从前端发请求？
+    │
+    ├─ 目标是平台内置 capability / Dataloom？
+    │   └─ 是 ──→ 用对应 SDK，不走 forwarder
+    │
+    ├─ 目标是公网公共 API（github.com 等）？
+    │   └─ 是 ──→ 直接 fetch / axios（不走 forwarder）
+    │
+    ├─ 目标是客户内网 HTTP/HTTPS API？
+    │   └─ 是 ──→ ✅ 用 forwarder：axiosForBackend + `/api/__platform__/http-forward`
+    │
+    └─ 目标是 ws:// / file:// / 二进制流 / FormData？
+        └─ 是 ──→ ❌ 当前版本不支持，回退方案见"限制"小节
+```
+
+## 二、Quick reference
+
+| 项           | 值                                                                           |
+| ------------ | ---------------------------------------------------------------------------- |
+| 端点路径     | `ALL /api/__platform__/http-forward`                                     |
+| Query 参数   | `targetUrl` （必填，仅 `http://` / `https://`）                              |
+| 前端 SDK     | `axiosForBackend` from `@lark-apaas/client-toolkit/utils/getAxiosForBackend` |
+| HTTP method  | 透传：GET / POST / PUT / PATCH / DELETE / HEAD / OPTIONS                     |
+| Body 形态    | string / JSON-able object（axios 自动序列化） / null                         |
+| Headers      | 自动透传（剔除 hop-by-hop / accept-encoding / host / content-length）        |
+| 响应         | 上游 `status` / `headers` / `data` 原样投射                                  |
+| 默认超时     | 30000 ms（可在 `PlatformModule.forRoot({ httpForwarder })` 改）              |
+| 默认响应上限 | 10485760 bytes (10 MB)                                                       |
+| 鉴权         | SDK **不内置**；业务方在路由上加 `@NeedLogin()` 等 guard                     |
+
+## 三、标准前端代码模板
+
+```ts
+// client/src/api/corp-api.ts
+import { axiosForBackend } from "@lark-apaas/client-toolkit/utils/getAxiosForBackend";
+
+const FORWARD = "/api/__platform__/http-forward";
+const BASE = "http://api.corp.com/v1";
+
+// GET — 拉用户列表
+export async function fetchUsers() {
+  const res = await axiosForBackend.get(FORWARD, {
+    params: { targetUrl: `${BASE}/users` },
+  });
+  return res.data; // 上游真实响应 data
+}
+
+// POST — 创建订单，body 直接传对象
+export async function createOrder(payload: { qty: number }) {
+  const res = await axiosForBackend.post(FORWARD, payload, {
+    params: { targetUrl: `${BASE}/orders` },
+    headers: { "X-Tenant": "demo" }, // 自定义 headers 自动透传上游
+  });
+  return res.data;
+}
+
+// DELETE — 路径参数拼在 targetUrl 上
+export async function deleteOrder(id: string) {
+  await axiosForBackend.delete(FORWARD, {
+    params: { targetUrl: `${BASE}/orders/${id}` },
+  });
+}
+```
+
+## 四、错误处理模板
+
+> ⚠️ 模板的 `GlobalExceptionFilter`（`server/common/filters/exception.filter.ts`）会把 forwarder 抛的 `HttpException` 重新打包为 `{ error: { code: 'BAD_REQUEST' | 'BAD_GATEWAY' | ..., message, details } }`：顶层 `error.code` 是 HTTP 状态映射，**forwarder 自己的业务码（`INVALID_REQUEST` / `UPSTREAM_TIMEOUT` 等）被 `JSON.stringify` 进 `error.details`**，需要 `JSON.parse` 才能拿到。
+
+```ts
+import { axiosForBackend } from "@lark-apaas/client-toolkit/utils/getAxiosForBackend";
+import type { AxiosError } from "axios";
+
+type ForwarderInner = { code?: string; message?: string };
+type ApiError = {
+  error?: { code?: string; message?: string; details?: string };
+};
+
+function parseForwarder(err: unknown): ForwarderInner | undefined {
+  const details = (err as AxiosError<ApiError>)?.response?.data?.error?.details;
+  if (typeof details !== "string") return undefined;
+  try {
+    return JSON.parse(details) as ForwarderInner;
+  } catch {
+    return undefined;
+  }
+}
+
+export async function safeForward(targetUrl: string) {
+  try {
+    const res = await axiosForBackend.get("/api/__platform__/http-forward", {
+      params: { targetUrl },
+    });
+    // 上游 4xx/5xx 也走这里：res.status 是上游真实 status
+    return { ok: true, status: res.status, data: res.data };
+  } catch (err) {
+    // 只有 forwarder 自身错才走 catch
+    const inner = parseForwarder(err);
+    switch (inner?.code) {
+      case "INVALID_REQUEST":
+      case "INVALID_TARGET_PROTOCOL":
+        // targetUrl 缺失 / 格式非法 / 协议非 http(s)
+        return { ok: false, reason: "targetUrl 配置错误" };
+      case "UPSTREAM_TIMEOUT":
+        return { ok: false, reason: "上游 30s 超时" };
+      case "UPSTREAM_UNREACHABLE":
+        // DNS 解析失败 / 连接拒绝 / 网络层不可达；
+        // inner.message 形如 "upstream unreachable (ENOTFOUND)"，括号里是 cause code
+        return { ok: false, reason: inner.message ?? "上游不可达" };
+      case "RESPONSE_TOO_LARGE":
+        return { ok: false, reason: "上游响应 > 10MB" };
+      default:
+        throw err;
+    }
+  }
+}
+```
+
+## 五、生成代码必须遵守的 6 条
+
+1. **路径恒为 `/api/__platform__/http-forward`**，HTTP method 来自调用方，service 透传给上游。
+2. **`targetUrl` 永远放 `params`**，不要拼到 URL 字符串里、不要放 body、不要放 header。
+3. **服务端零接入**——`PlatformModule.forRoot()` 已自动装配 `HttpForwarderModule`，**不要**在用户 `AppModule` 里再写 `HttpForwarderModule.forRoot()`。
+4. **前端只用 `axiosForBackend`**，它已带 401 → `x-login-url` 自动跳转拦截器，**不要**再实现登录跳转。
+5. **响应原样投射**：`res.status` / `res.headers` / `res.data` 都来自上游真实响应。forwarder 自身错被模板 `GlobalExceptionFilter` 包成 `error.response.data.error`，业务码需从 `error.details`（JSON 字符串）里 parse 出来，详见第四节。
+6. **headers 直接走 `headers: {...}`**，无需手剔 `host` / `content-length` / hop-by-hop，service 端会处理。
+
+## 六、Common Mistakes
+
+| ❌ 错误                                                                               | ✅ 正确                                                                                                                        |
+| ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
+| `axiosForBackend.post('/api/__platform__/http-forward?targetUrl=...')` 手拼 query | `params: { targetUrl }`，让 axios 做 URL 编码                                                                                  |
+| `axiosForBackend.post(targetUrl, body)` 把 targetUrl 当路径                           | 路径永远 `/api/__platform__/http-forward`，targetUrl 走 `params`                                                           |
+| 用裸 `axios.get('/api/__platform__/http-forward', ...)`（直接 import 'axios'）    | 用 `axiosForBackend`（带 baseURL / 401 拦截器）                                                                                |
+| body 传 `FormData` / `Blob` / 流                                                      | v0.1.0 仅支持 string / JSON-able；二进制走 base64 字符串                                                                       |
+| 上游 4xx/5xx 被当作转发失败                                                           | 上游响应**原样投射**到 `res`；只有 forwarder 自身错才进 catch，业务码在 `error.response.data.error.details`（需 `JSON.parse`） |
+| 用户 `AppModule` 手写 `HttpForwarderModule.forRoot()`                                 | 已被 `PlatformModule` 自动装配，重复注册冲突                                                                                   |
+| 拼 `?targetUrl=...&proxy_group_id=xxx&jwt=yyy` 等自定义参数                           | 部署环境接管路由，SDK 不感知；唯一参数是 `targetUrl`                                                                           |
+| `targetUrl: 'ws://...'` / `'file://...'`                                              | 仅 `http://` / `https://`，否则 `INVALID_TARGET_PROTOCOL`                                                                      |
+| 在生成代码里手动加 `Authorization` 模拟 anycross                                      | 部署环境处理鉴权，业务代码只关心**业务**header                                                                                 |
+| 假设响应可流式读取                                                                    | 当前版本响应统一 utf-8 string，不流式                                                                                          |
+
+## 七、限制（v0.1.0）
+
+- **Body**：仅 `string` / JSON-able object / `null`；不支持 binary / FormData / 流
+- **响应**：统一 utf-8 string；不支持流式 / 二进制下载
+- **不做请求重试**（透传语义，重试由业务方决定）
+- **超时 / 响应上限可配**：业务方可在 `PlatformModule.forRoot({ httpForwarder: { requestTimeoutMs, maxResponseBytes } })` 处覆盖默认值
+- **错误码 contract**：`INVALID_REQUEST` / `INVALID_TARGET_PROTOCOL` / `UPSTREAM_UNREACHABLE` / `UPSTREAM_TIMEOUT` / `RESPONSE_TOO_LARGE`
+
+## 八、相关
+
+- 后端 SDK 实现：`@lark-apaas/nestjs-http-forwarder`
+- 前端 SDK：`axiosForBackend` from `@lark-apaas/client-toolkit/utils/getAxiosForBackend`
+- 自动装配点：`@lark-apaas/nestjs-core` 的 `PlatformModule`
+- 鉴权约束：参见 `user-identity`——forwarder 不内置鉴权，路由级 `@NeedLogin()` 仍生效