create-yss-spec 3.0.0 → 3.1.0

package/template/.hermes/skills/page-skeleton/examples/AdvancedFormPage/style.less

@@ -1,30 +0,0 @@
-.rule-config-page {
-  width: 100%;
-  height: 100%;
-
-  &__content {
-    height: 100%;
-    overflow: auto;
-  }
-
-  &__preview {
-    display: flex;
-    align-items: flex-start;
-    gap: 12px;
-
-    pre {
-      flex: 1;
-      min-height: 72px;
-      max-height: 220px;
-      margin: 0;
-      padding: 12px;
-      overflow: auto;
-      color: var(--text-color, rgb(0 0 0 / 88%));
-      background: var(--bg-color, #f0f2f5);
-      border: 1px solid var(--border-color-split, #f0f0f0);
-      border-radius: 6px;
-      white-space: pre-wrap;
-      word-break: break-word;
-    }
-  }
-}

package/template/.hermes/skills/page-skeleton/examples/StandardListPage/constant.ts

@@ -1,28 +0,0 @@
-import type { YTableColumn } from '@yss-ui/components';
-import type { QualityBusinessRuleVO } from '@/api/generated/quality/schemas';
-
-/** 质量规则列表行数据。 */
-export type QualityRuleItem = QualityBusinessRuleVO;
-
-/** 质量规则查询表单。 */
-export interface SearchFormData {
-  ruleName: string;
-}
-
-/** 状态文案映射。 */
-export const STATUS_LABELS: Record<number, string> = {
-  0: '禁用',
-  1: '启用',
-};
-
-/** 质量规则表格列。 */
-export const TABLE_COLUMNS: YTableColumn[] = [
-  { field: 'ruleName', title: '质量规则名称', minWidth: 180, slots: { default: 'ruleName' } },
-  { field: 'ruleCode', title: '规则编码', minWidth: 160 },
-  {
-    field: 'status',
-    title: '状态',
-    width: 100,
-    formatter: ({ cellValue }: { cellValue?: number }) => STATUS_LABELS[cellValue ?? -1] ?? '-',
-  },
-];

package/template/.hermes/skills/page-skeleton/examples/StandardListPage/hooks/useQualityRuleList.ts

@@ -1,58 +0,0 @@
-import { reactive, ref } from 'vue';
-import { getApiApi } from '@/api/generated/quality';
-import type { QualityRulePage } from '@/api/generated/quality/schemas';
-import type { QualityRuleItem, SearchFormData } from '../constant';
-
-const { pageQualityRule } = getApiApi();
-
-/** 管理质量规则列表、查询和远程分页。 */
-export const useQualityRuleList = () => {
-  const tableData = ref<QualityRuleItem[]>([]);
-  const loading = ref(false);
-  const pagination = reactive({ current: 1, pageSize: 20, total: 0, remote: true });
-  const searchForm = reactive<SearchFormData>({ ruleName: '' });
-
-  /** 组装 Orval 查询 DTO。 */
-  const getQueryParams = (): QualityRulePage => ({
-    pageIndex: pagination.current,
-    pageSize: pagination.pageSize,
-    ruleName: searchForm.ruleName || undefined,
-  });
-
-  /** 加载列表；错误提示由 mutator 统一处理。 */
-  const fetchList = async (): Promise<void> => {
-    loading.value = true;
-    try {
-      const res = await pageQualityRule(getQueryParams());
-      tableData.value = res.data ?? [];
-      pagination.total = res.totalCount ?? 0;
-    } catch {
-      tableData.value = [];
-      pagination.total = 0;
-    } finally {
-      loading.value = false;
-    }
-  };
-
-  /** 处理分页变化。 */
-  const handlePageChange = ({ current, pageSize }: { current: number; pageSize: number }): void => {
-    pagination.current = current;
-    pagination.pageSize = pageSize;
-    void fetchList();
-  };
-
-  /** 从第一页执行查询。 */
-  const handleSearch = (): void => {
-    pagination.current = 1;
-    void fetchList();
-  };
-
-  /** 重置查询条件并刷新。 */
-  const handleReset = (): void => {
-    searchForm.ruleName = '';
-    pagination.current = 1;
-    void fetchList();
-  };
-
-  return { tableData, loading, pagination, searchForm, fetchList, handlePageChange, handleSearch, handleReset };
-};

package/template/.hermes/skills/page-skeleton/examples/StandardListPage/hooks/useRuleActions.ts

@@ -1,65 +0,0 @@
-import { computed } from 'vue';
-import { message } from 'ant-design-vue';
-import type { YTableActionConfig } from '@yss-ui/components';
-import { getApiApi } from '@/api/generated/quality';
-import type { QualityRuleItem } from '../constant';
-
-const { deleteQualityRule } = getApiApi();
-
-/** 行操作与页面容器的通信回调。 */
-export interface RuleActionCallbacks {
-  refreshList: () => Promise<void>;
-  onCreate: () => void;
-  onEdit: (row: QualityRuleItem) => void;
-  onView: (row: QualityRuleItem) => void;
-}
-
-/** YTable 气泡确认助手。 */
-interface ActionHelpers {
-  close: () => void;
-  hideLoading: () => void;
-}
-
-/** 管理质量规则行操作和 YTable 操作列配置。 */
-export const useRuleActions = (callbacks: RuleActionCallbacks) => {
-  /** 删除规则并刷新列表。 */
-  const handleDelete = async (row: QualityRuleItem): Promise<void> => {
-    if (!row.id) return;
-
-    try {
-      await deleteQualityRule(row.id);
-      message.success('删除成功');
-      await callbacks.refreshList();
-    } catch {
-      // mutator 已展示错误，此处不重复 message.error。
-    }
-  };
-
-  /** 标准操作列：查看/编辑立即执行，删除使用气泡确认。 */
-  const actionConfig = computed<YTableActionConfig>(() => ({
-    title: '操作',
-    width: 180,
-    fixed: 'right',
-    buttons: [
-      { label: '查看', value: 'view', click: ({ row }) => callbacks.onView(row) },
-      { label: '编辑', value: 'edit', click: ({ row }) => callbacks.onEdit(row) },
-      {
-        label: '删除',
-        value: 'delete',
-        type: 'link',
-        isConfirm: true,
-        confirmProps: { title: '确认删除此规则吗？删除后无法恢复', needLoading: true },
-        click: async ({ row }, _button, helpers: ActionHelpers) => {
-          try {
-            await handleDelete(row);
-          } finally {
-            helpers.hideLoading();
-            helpers.close();
-          }
-        },
-      },
-    ],
-  }));
-
-  return { actionConfig, handleCreate: callbacks.onCreate };
-};

package/template/.hermes/skills/page-skeleton/examples/StandardListPage/index.vue

@@ -1,91 +0,0 @@
-<script setup lang="ts">
-import { onMounted, ref } from 'vue';
-import { Input as AInput } from 'ant-design-vue';
-import { YButton, YCard, YTable } from '@yss-ui/components';
-import { useTableHeight } from '@yss-ui/hooks';
-import { TABLE_COLUMNS, type QualityRuleItem } from './constant';
-import { useQualityRuleList } from './hooks/useQualityRuleList';
-import { useRuleActions } from './hooks/useRuleActions';
-
-defineOptions({ name: 'StandardListPage' });
-
-const emit = defineEmits<{
-  create: [];
-  edit: [row: QualityRuleItem];
-  view: [row: QualityRuleItem];
-}>();
-
-const tableAreaRef = ref<HTMLDivElement>();
-const { tableHeight, isReady } = useTableHeight(tableAreaRef, {
-  withPagination: true,
-  withToolbar: true,
-});
-const { tableData, loading, pagination, searchForm, fetchList, handlePageChange, handleSearch, handleReset } =
-  useQualityRuleList();
-const { actionConfig, handleCreate } = useRuleActions({
-  refreshList: fetchList,
-  onCreate: () => emit('create'),
-  onEdit: row => emit('edit', row),
-  onView: row => emit('view', row),
-});
-
-/** 查看规则详情。 */
-const handleRuleNameClick = (row: QualityRuleItem): void => {
-  emit('view', row);
-};
-
-onMounted(() => {
-  void fetchList();
-});
-</script>
-
-<template>
-  <div class="quality-rule-page">
-    <YCard class="quality-rule-page__search-card">
-      <div class="quality-rule-page__search-content">
-        <AInput
-          v-model:value="searchForm.ruleName"
-          class="quality-rule-page__keyword"
-          placeholder="请输入规则名称"
-          allow-clear
-          @press-enter="handleSearch"
-        />
-        <div class="quality-rule-page__search-actions">
-          <YButton @click="handleReset">重置</YButton>
-          <YButton type="primary" :loading="loading" @click="handleSearch">查询</YButton>
-        </div>
-      </div>
-    </YCard>
-
-    <YCard class="quality-rule-page__table-card">
-      <div ref="tableAreaRef" class="quality-rule-page__table-area">
-        <YTable
-          v-if="isReady"
-          :data="tableData"
-          :columns="TABLE_COLUMNS"
-          :loading="loading"
-          :height="tableHeight"
-          :action-config="actionConfig"
-          :toolbar-config="{ custom: true }"
-          pageable
-          v-model:pagination="pagination"
-          @page-change="handlePageChange"
-        >
-          <template #toolbar-right>
-            <YButton @click="fetchList">刷新</YButton>
-            <YButton type="primary" @click="handleCreate">新增质量规则</YButton>
-          </template>
-          <template #ruleName="{ row }">
-            <button class="quality-rule-page__rule-link" type="button" @click="handleRuleNameClick(row)">
-              {{ row.ruleName ?? '-' }}
-            </button>
-          </template>
-        </YTable>
-      </div>
-    </YCard>
-  </div>
-</template>
-
-<style scoped lang="less">
-@import url('./style.less');
-</style>

package/template/.hermes/skills/page-skeleton/examples/StandardListPage/style.less

@@ -1,49 +0,0 @@
-.quality-rule-page {
-  display: flex;
-  flex-direction: column;
-  width: 100%;
-  height: 100%;
-  min-height: 0;
-  gap: 12px;
-
-  &__search-content {
-    display: flex;
-    flex-direction: column;
-    gap: 12px;
-  }
-
-  &__keyword {
-    width: min(100%, 360px);
-  }
-
-  &__search-actions {
-    display: flex;
-    justify-content: flex-end;
-    gap: 8px;
-  }
-
-  &__table-card,
-  &__table-area {
-    flex: 1;
-    min-height: 0;
-  }
-
-  &__rule-link {
-    padding: 0;
-    color: var(--primary-color, #3371ff);
-    background: transparent;
-    border: 0;
-    cursor: pointer;
-
-    &:hover,
-    &:focus-visible {
-      color: var(--primary-color-hover, #4096ff);
-      text-decoration: underline;
-    }
-
-    &:focus-visible {
-      outline: 2px solid color-mix(in srgb, var(--primary-color, #3371ff) 35%, transparent);
-      outline-offset: 2px;
-    }
-  }
-}

package/template/.hermes/skills/prototype/LOGIC.md

@@ -1,67 +0,0 @@
-# Logic Prototype
-
-A single, self-contained HTML file — a **shareable demo** — that lets anyone drive a state model by clicking buttons. Use this when the question is about **business logic, state transitions, or data shape** — the kind of thing that looks reasonable on paper but only feels wrong once you push it through real cases.
-
-Because it's one file with nothing to install, you can hand it to a non-developer — a designer, a PM, a domain expert — and let them feel the model for themselves. So it speaks their language, not the code's.
-
-## When this is the right shape
-
-- "I'm not sure if this state machine handles the edge case where X then Y."
-- "Does this data model actually let me represent the case where..."
-- "I want to feel out what the API should look like before writing it."
-- Anything where someone wants to **press buttons and watch state change**.
-
-If the question is "what should this look like" — wrong branch. Use [UI.md](UI.md).
-
-## Process
-
-### 1. State the question
-
-Before writing code, write down what state model and what question you're prototyping. One paragraph, at the top of the demo (in a visible intro, not just a comment). A logic prototype that answers the wrong question is pure waste — make the question explicit so it can be checked later, whether the user is watching now or returning to it AFK.
-
-### 2. Isolate the logic in a portable module
-
-Put the actual logic — the bit that's answering the question — in a single `<script>` block written as a small, pure module that could be lifted out and dropped into the real codebase later. The page around it is throwaway; this module isn't.
-
-The right shape depends on the question:
-
-- **A pure reducer** — `(state, action) => state`. Good when actions are discrete events and state is a single value.
-- **A state machine** — explicit states and transitions. Good when "which actions are even legal right now" is part of the question.
-- **A small set of pure functions** over a plain data type. Good when there's no implicit current state — just transformations.
-- **A class or module with a clear method surface** when the logic genuinely owns ongoing internal state.
-
-Pick whichever shape best fits the question being asked, *not* whichever is easiest to wire to a page. Keep it pure: no DOM, no `document`, no button handlers reaching inside it. The page calls into it; nothing flows the other direction. This is what makes the prototype useful past its own lifetime: once the question's answered, the validated reducer / machine / function set lifts into the real module on its own.
-
-### 3. Build the shareable HTML file
-
-One file, plain HTML/CSS/JS — no framework, no bundler, no server, everything inline so it opens by double-click and survives being emailed around. Anyone should be able to run it by opening it.
-
-Write it for a non-developer. Every label is in **domain language**, not code — buttons and state read like the business, not the reducer. Explain in plain words what's happening.
-
-Lay it out with a clean hierarchy, top to bottom:
-
-1. **Title and one-line explanation** of what this demo lets you explore (the question from step 1).
-2. **Current state** — the full relevant state, rendered as a readable panel (labelled fields, not a raw JSON dump), re-rendered after every click so the change is visible. Where it helps a non-developer follow, call out what just changed.
-3. **Free-play buttons** — one button per action, always available, so anyone can poke at the model in any order. Each click dispatches its action and re-renders the state.
-4. **Guided walkthroughs** — a set of **scenarios**, one per tab. Each tab holds a short plain-language description of the scenario — the situation it sets up and what to watch for — and underneath it, the ordered **buttons to press** for that scenario. Each step is a real button: clicking it performs that action and moves to the next step. Starting a walkthrough resets to a known initial state so the scenario runs the same way every time.
-
-Choose scenarios that demonstrate the awkward cases — the happy path, a tricky edge case, an attempt at something that should be illegal — the ones hard to reason about on paper.
-
-Keep it beautiful but restrained: clean typography, generous spacing, one accent colour. No animations, no gimmicks — nothing that competes with the state and the buttons.
-
-### 4. Hand it over
-
-Send them the file, or open it for them. They'll click through the walkthroughs and free-play whenever they get to it; the interesting moments are when they say "wait, that shouldn't be possible" or "huh, I assumed X would be different" — those are the bugs in the _idea_, which is the whole point. If they want new actions or a new scenario, add them. Prototypes evolve.
-
-### 5. Capture the answer and the prototype
-
-Once the prototype has answered its question, capture the answer, then capture the prototype the way the [SKILL](SKILL.md) describes. The logic-specific mapping: the validated reducer / machine / function set lifts into the real module (the decision, absorbed); the HTML shell rides along to the throwaway branch that keeps the prototype as a primary source — and being one self-contained file, it stays trivially re-runnable there.
-
-## Anti-patterns
-
-- **Don't add tests.** A prototype that needs tests is no longer a prototype.
-- **Don't wire it to the real database.** Use in-memory state unless the question is specifically about persistence.
-- **Don't generalise.** No "what if we wanted to support X later." The prototype answers one question.
-- **Don't blur the logic and the page together.** If the pure module references the DOM, `document`, or button handlers, it's no longer liftable. Keep the page as a thin shell over a pure module.
-- **Don't reach for a framework, bundler, or server.** One file the recipient double-clicks; a React app or a dev server defeats "shareable".
-- **Don't ship the HTML shell into production.** The page is optimised for being clicked through by hand. The logic module behind it is the bit worth keeping.

package/template/.hermes/skills/prototype/SKILL.md

@@ -1,26 +0,0 @@
----
-name: prototype
-description: Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
----
-
-# Prototype
-
-A prototype is **throwaway code that answers a question**. The question decides the shape.
-
-## Pick a branch
-
-Identify which question is being answered — from the user's prompt, the surrounding code, or by asking if the user is around:
-
-- **"Does this logic / state model feel right?"** → [LOGIC.md](LOGIC.md). Build a single shareable HTML file — free-play buttons plus tabbed guided walkthroughs — that pushes the state machine through cases that are hard to reason about on paper, and that a non-developer can drive.
-- **"What should this look like?"** → [UI.md](UI.md). Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.
-
-The two branches produce very different artifacts — getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.
-
-## Rules that apply to both
-
-1. **Throwaway from day one, and clearly marked as such.** Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious — but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure.
-2. **Trivial to run.** A UI prototype starts from one command in the project's task runner — `pnpm <name>`, `python <path>`, `bun <path>`, etc. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
-3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is _checking_, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE — wipe me" name.
-4. **Skip the polish.** No tests, no error handling beyond what makes the prototype _runnable_, no abstractions. The point is to learn something fast.
-5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
-6. **Capture it when done.** Fold any validated decision into the real code, then capture the prototype itself as a **primary source**: commit it to a throwaway branch, out of main, and leave a context pointer to that branch on the implementation issue. Capture the answer too — the verdict and the question it settled — in the issue or a commit. The main branch keeps only the validated decision.

package/template/.hermes/skills/prototype/UI.md

@@ -1,112 +0,0 @@
-# UI Prototype
-
-Generate **several radically different UI variations** on a single route, switchable from a floating bottom bar. The user flips between variants in the browser, picks one (or steals bits from each), then throws the rest away.
-
-If the question is about logic/state rather than what something looks like — wrong branch. Use [LOGIC.md](LOGIC.md).
-
-## When this is the right shape
-
-- "What should this page look like?"
-- "I want to see a few options for this dashboard before committing."
-- "Try a different layout for the settings screen."
-- Any time the user would otherwise spend a day picking between three vague mockups in their head.
-
-## Two sub-shapes — strongly prefer sub-shape A
-
-A UI prototype is much easier to judge when it's **butting up against the rest of the app** — real header, real sidebar, real data, real density. A throwaway route on its own is a vacuum: every variant looks fine in isolation. Default to sub-shape A whenever there's a plausible existing page to host the variants. Only reach for sub-shape B if the prototype genuinely has no nearby home.
-
-### Sub-shape A — adjustment to an existing page (preferred)
-
-The route already exists. Variants are rendered **on the same route**, gated by a `?variant=` URL search param. The existing data fetching, params, and auth all stay — only the rendering swaps. This is the default; pick it unless there's a specific reason not to.
-
-If the prototype is for something that doesn't yet have a page but *would naturally live inside one* (a new section of the dashboard, a new card on the settings screen, a new step in an existing flow) — that's still sub-shape A. Mount the variants inside the host page.
-
-### Sub-shape B — a new page (last resort)
-
-Only use this when the thing being prototyped genuinely has no existing page to live inside — e.g. an entirely new top-level surface, or a flow that can't be embedded anywhere sensible.
-
-Create a **throwaway route** following whatever routing convention the project already uses — don't invent a new top-level structure. Name it so it's obviously a prototype (e.g. include the word `prototype` in the path or filename). Same `?variant=` pattern.
-
-Before committing to sub-shape B, sanity-check: is there really no existing page this could be embedded in? An empty route hides design problems that a populated one would expose.
-
-In both sub-shapes the floating bottom bar is identical.
-
-## Process
-
-### 1. State the question and pick N
-
-Default to **3 variants**. More than 5 stops being radically different and starts being noise — cap there.
-
-Write down the plan in one line, in the prototype's location or a top-of-file comment:
-
-> "Three variants of the settings page, switchable via `?variant=`, on the existing `/settings` route."
-
-This works whether the user is here to push back or not.
-
-### 2. Generate radically different variants
-
-Draft each variant. Hold each one to:
-
-- The page's purpose and the data it has access to.
-- The project's component library / styling system (TailwindCSS, shadcn, MUI, plain CSS, whatever).
-- A clear exported component name, e.g. `VariantA`, `VariantB`, `VariantC`.
-
-Variants must be **structurally different** — different layout, different information hierarchy, different primary affordance, not just different colours. Three slightly-tweaked card grids isn't a UI prototype, it's wallpaper. If two drafts come out too similar, redo one with explicit "do not use a card grid" guidance.
-
-### 3. Wire them together
-
-Create a single switcher component on the route:
-
-```tsx
-// pseudo-code — adapt to the project's framework
-const variant = searchParams.get('variant') ?? 'A';
-return (
-  <>
-    {variant === 'A' && <VariantA {...data} />}
-    {variant === 'B' && <VariantB {...data} />}
-    {variant === 'C' && <VariantC {...data} />}
-    <PrototypeSwitcher variants={['A','B','C']} current={variant} />
-  </>
-);
-```
-
-For sub-shape A (existing page): keep all the existing data fetching above the switcher; only the rendered subtree changes per variant.
-
-For sub-shape B (new page): the throwaway route under `/prototype/<name>` mounts the same switcher.
-
-### 4. Build the floating switcher
-
-A small fixed-position bar at the bottom-centre of the screen with three pieces:
-
-- **Left arrow** — cycles to the previous variant (wraps around).
-- **Variant label** — shows the current variant key and, if the variant exports a name, that name too. e.g. `B — Sidebar layout`.
-- **Right arrow** — cycles forward (wraps around).
-
-Behaviour:
-
-- Clicking an arrow updates the URL search param (use the framework's router — `router.replace` on Next, `navigate` on React Router, etc) so the variant is shareable and reload-stable.
-- Keyboard: `←` and `→` arrow keys also cycle. Don't intercept arrow keys when an `<input>`, `<textarea>`, or `[contenteditable]` is focused.
-- Visually distinct from the page (e.g. high-contrast pill, subtle shadow) so it's obviously not part of the design being evaluated.
-- Hidden in production builds — gate on `process.env.NODE_ENV !== 'production'` or an equivalent check, so a stray prototype merge can't ship the bar to users.
-
-Put the switcher in a single shared component so both sub-shapes can reuse it. Locate it wherever shared UI lives in the project.
-
-### 5. Hand it over
-
-Surface the URL (and the `?variant=` keys). The user will flip through whenever they get to it. The interesting feedback is usually **"I want the header from B with the sidebar from C"** — that's the actual design they want.
-
-### 6. Capture the answer and clean up
-
-Once a variant has won, capture the answer — which variant and why — then capture the prototype the way the [SKILL](SKILL.md) describes. Fold the winner into the real code and move the rest onto the throwaway branch, not into main:
-
-- **Sub-shape A** — fold the winner into the existing page; drop the losing variants and the switcher from main.
-- **Sub-shape B** — promote the winning variant to a real route; drop the throwaway route and the switcher from main.
-
-The full set of variants is the primary source, so it lands on the throwaway branch, not the bin — variant components and the switcher left in the main branch rot fast and confuse the next reader.
-
-## Anti-patterns
-
-- **Variants that differ only in colour or copy.** That's a tweak, not a prototype. Real variants disagree about structure.
-- **Sharing too much code between variants.** A shared `<Header>` is fine; a shared `<Layout>` defeats the point. Each variant should be free to throw out the layout.
-- **Wiring variants to real mutations.** Read-only prototypes are fine. If a variant needs to mutate, point it at a stub — the question is "what should this look like", not "does the backend work".
-- **Promoting the prototype directly to production.** The variant code was written under prototype constraints (no tests, minimal error handling). Rewrite it properly when you fold it in.

package/template/.hermes/skills/prototype/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "Prototype"
-  short_description: "Prototype to answer a design question"

package/template/.hermes/skills/prototype-page-acceptance/SKILL.md

@@ -1,62 +0,0 @@
----
-name: prototype-page-acceptance
-description: 当用户提供原型截图、老项目路径、旧页面截图或要求按既有页面复刻业务页面时，指导先提取视觉和交互验收清单，开发后用截图/运行结果逐项对照，避免只实现字段而忽略布局、按钮、表格高度和控件类型。
----
-
-# 原型页面还原验收 Skill
-
-## 触发条件
-
-- 用户提供原型图、截图、设计稿、旧项目 view/logic/service 路径。
-- 用户要求“参考老项目、照原型、复刻页面、保持和旧系统一致”。
-- 开发结果需要人工视觉对照，而不只是接口和类型正确。
-
-## 不适用场景
-
-- 纯逻辑修复、纯 API 对接、无 UI 改动。
-- 用户明确要求自由设计，不需要贴近旧页面。
-- 组件库内部能力开发，不涉及业务页面还原。
-
-## 硬约束（禁止/必须）
-
-- 开发前必须打开用户给出的旧项目 view 文件、相关 logic/service 文件和当前项目相近页面，不得只看接口。
-- 必须把截图/旧页面拆成验收清单：查询区布局、按钮位置、表格工具栏、表格高度/分页、操作列、弹窗/抽屉尺寸、表单 label 宽度和对齐、FormGrid 响应式、字段控件类型。
-- Vue3 + YSS UI 列表查询区默认验收“字段在上、查询/重置按钮独占下一行并右对齐”；缩放或窄屏导致字段换行时，按钮必须仍在搜索卡片右下角，不得贴在第一行字段旁。
-- 若截图里出现但需求文字没写的通用交互（查询/重置、表格列设置、新增按钮位置、分页器、抽屉底部按钮），默认按截图实现。
-- 不允许用“用户没说”跳过截图里明显存在的 UI；只有业务含义不明时才询问。
-- 开发后必须运行页面或至少完成类型/构建检查；可运行时必须截图对照首屏和关键弹窗/抽屉。
-- 交付说明必须列出“已对照原型的验收项”和“未能验证的项”。
-
-## 标准代码骨架
-
-```text
-原型验收清单：
-- 查询区：字段数量、FormGrid 响应式列数、label 固定宽度和右对齐、查询/重置按钮右下角位置，缩窄后按钮不贴第一行字段。
-- 表格区：YTable、toolbar-config.custom、#toolbar-right 新增按钮、分页、无底部大空白。
-- 操作列：按钮可见条件、更多菜单、删除气泡确认文案。
-- 抽屉/弹窗：响应式宽度、底部按钮、查看态只读、label 右对齐且宽度统一、缩窄时 2 列变 1 列、备注/长文本占满行。
-- 编辑表格：使用 YEditTable，列控件类型、可输入/多选、添加行/删除行、校验。
-```
-
-```text
-验收输出：
-- 通过：查询区三列栅格，查询/重置按钮独占下一行并右对齐；缩窄到字段两行或三行时按钮仍在搜索卡片右下角。
-- 通过：表格工具栏右侧为新增和列设置按钮，分页贴底显示，无大空白。
-- 通过：抽屉宽度使用 min(90vw, 1200px)，labelWidth 固定且右对齐，FormGrid 从 2 列响应式收缩为 1 列，查看态不显示保存。
-- 未验证：后端真实数据返回为空，仅用 mock/空态验证布局。
-```
-
-## 交付检查清单
-
-- [ ] 已读取旧项目 view/logic/service 或当前相近页面。
-- [ ] 已把截图中可见 UI 转成验收清单。
-- [ ] 查询/重置按钮右下角布局、表格工具栏、新增按钮、分页和空白高度已对照。
-- [ ] 抽屉/弹窗响应式、label 宽度和右对齐、FormGrid 换列、底部按钮已对照。
-- [ ] 编辑表格控件类型、可输入/多选、添加/删除已对照。
-- [ ] 已运行类型检查、构建或浏览器截图验证，并说明未验证项。
-
-## 失败兜底策略
-
-- 旧项目代码太复杂时，先提取最终 UI 结构和字段映射，再复用当前项目组件实现。
-- 截图与文字需求冲突时，优先按文字业务规则，UI 布局仍尽量按截图；冲突点写入交付说明。
-- 无法运行项目时，至少执行静态类型检查并逐项说明哪些视觉项未验证。