From 8160f91559712d498e462a2a098af7a1b5bedc53 Mon Sep 17 00:00:00 2001 From: maogeigei Date: Fri, 16 Oct 2026 23:13:33 +0800 Subject: [PATCH] =?UTF-8?q?=E6=8A=80=E8=83=BD=E5=BA=93=E5=90=8C=E6=AD=A5?= =?UTF-8?q?=EF=BC=9A=E5=8F=A6=E4=B8=80=E5=8F=B0=E6=9C=BA=E7=9A=84=202026-1?= =?UTF-8?q?0-16=20=E5=8C=85=20=EF=BC=8B=20element-picker=20=E5=85=A5?= =?UTF-8?q?=E5=8C=85=20=EF=BC=8B=20=E5=B7=A5=E5=85=B7=E5=BD=92=E6=8B=A2?= =?UTF-8?q?=E5=88=B0=E6=8A=80=E8=83=BD=E7=BA=A7=20assets/?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit product-planning（同步 26 改 65 新） - 目录约定：docs/pm/<项目>/ ⇒ <工作区>/项目/<产品slug>/ 为产品根，下分 产品规划/ 与 产品原型/{designs,pages} - ④段骨架六节 ⇒ 七节（新增「原型地址」；后两节改「页面导航」「原型状态取值」） - ③段新增真机组件库；结案「源站只有暗色主题」，tokens.css（亮色）标为不可用于生产 - ③段改版规则反转为「一个产品只用一套原型、只留当前态」；②段新增 产品规划模板.md（表头唯一定义处） - scripts：产品根定位重写（含 .registry/current-project 指针），新增 check_terms.py 与 selftest_product_root.py session-mechanism（同步 3 改 2 新） - references/06-技能优化规程.md 新增 §5「要求落在生成时看得见的面上」，总表 16 ⇒ 17 条；SKILL.md 同步 - scripts/collabctl.py 取回 _find_board() 候选定位（旧版写死 scripts/board.py，而看板已搬进 boards/会话看板/ ⇒ 旧版本就是坏的） element-picker（新装） - 按用户口径作「独立功能加入 product-planning」，非独立全局技能 - 修掉它自身三处路径漂移（技能根写法 ⇒ 同目录；README 两处旧落点；剪贴板示例文案与代码对齐） 工具归拢到技能级 assets/ - diagram-design / design-capture / element-picker / video-capture 从各段 assets/ 移到技能包 assets/ - 新增红线：本包有两处 assets/（技能级工具箱 vs 段内资产），引工具一律写「技能级 assets/<工具名>/」 - 路径口径由两类改三类（技能级工具箱 / 本段自带资产 / 同根技能） 不入库（磁盘保留） - design-system-tiaoyue 整个目录（用户 2026-10-16 令）：git rm -r --cached ＋ .gitignore，理由＝14 MB 且可 CDP 重采； 已在 ③段 SKILL.md 注明「取仓后这一层是空的属正常，用自带套需另取或重采」 - element-picker 的运行期存档 marks/（服务自己会建目录） --- .gitignore | 10 + product-planning/SKILL.md | 89 +- .../assets/design-capture/ATTRIBUTION.md | 0 .../assets/design-capture/SKILL.md | 0 .../scripts/build_style_package.py | 0 .../scripts/capture_design_system.mjs | 0 .../design-capture/vendor/brand-capture.js | 0 .../assets/diagram-design/SKILL.md | 0 .../assets/example-architecture-dark.html | 0 .../assets/example-architecture-full.html | 0 .../assets/example-architecture.html | 0 .../assets/example-bar-dark.html | 0 .../assets/example-bar-full.html | 0 .../diagram-design/assets/example-bar.html | 0 .../assets/example-beeswarm-dark.html | 0 .../assets/example-beeswarm-full.html | 0 .../assets/example-beeswarm.html | 0 .../assets/example-bubble-dark.html | 0 .../assets/example-bubble-full.html | 0 .../diagram-design/assets/example-bubble.html | 0 .../assets/example-bump-dark.html | 0 .../assets/example-bump-full.html | 0 .../diagram-design/assets/example-bump.html | 0 .../assets/example-data-flow-dark.html | 0 .../assets/example-data-flow-full.html | 0 .../assets/example-data-flow.html | 0 .../assets/example-datalake-dark.html | 0 .../assets/example-datalake-full.html | 0 .../assets/example-datalake.html | 0 .../assets/example-db-schema-dark.html | 0 .../assets/example-db-schema-full.html | 0 .../assets/example-db-schema.html | 0 .../assets/example-dependency-dark.html | 0 .../assets/example-dependency-full.html | 0 .../assets/example-dependency.html | 0 .../assets/example-deployment-dark.html | 0 .../assets/example-deployment-full.html | 0 .../assets/example-deployment.html | 0 .../assets/example-dp-integration-dark.html | 0 .../assets/example-dp-integration-full.html | 0 .../assets/example-dp-integration.html | 0 .../example-dp-security-matrix-dark.html | 0 .../example-dp-security-matrix-full.html | 0 .../assets/example-dp-security-matrix.html | 0 .../assets/example-er-dark.html | 0 .../assets/example-er-full.html | 0 .../diagram-design/assets/example-er.html | 0 .../assets/example-fishbone-dark.html | 0 .../assets/example-fishbone-full.html | 0 .../assets/example-fishbone.html | 0 .../assets/example-flowchart-dark.html | 0 .../assets/example-flowchart-full.html | 0 .../assets/example-flowchart.html | 0 .../assets/example-gantt-dark.html | 0 .../assets/example-gantt-full.html | 0 .../diagram-design/assets/example-gantt.html | 0 .../assets/example-heatmap-dark.html | 0 .../assets/example-heatmap-full.html | 0 .../assets/example-heatmap.html | 0 .../assets/example-high-level-dark.html | 0 .../assets/example-high-level-full.html | 0 .../example-high-level-vertical-dark.html | 0 .../example-high-level-vertical-full.html | 0 .../assets/example-high-level-vertical.html | 0 .../assets/example-high-level.html | 0 .../assets/example-import-drawio.html | 0 .../assets/example-import-excalidraw.html | 0 .../assets/example-import-mermaid.html | 0 .../assets/example-it-state-dark.html | 0 .../assets/example-it-state-full.html | 0 .../assets/example-it-state.html | 0 .../assets/example-journey-dark.html | 0 .../assets/example-journey-full.html | 0 .../assets/example-journey.html | 0 .../assets/example-kanban-dark.html | 0 .../assets/example-kanban-full.html | 0 .../diagram-design/assets/example-kanban.html | 0 .../assets/example-layers-dark.html | 0 .../assets/example-layers-full.html | 0 .../diagram-design/assets/example-layers.html | 0 .../assets/example-line-dark.html | 0 .../assets/example-line-full.html | 0 .../diagram-design/assets/example-line.html | 0 .../assets/example-loop-dark.html | 0 .../assets/example-loop-full.html | 0 .../assets/example-loop-terminal.html | 0 .../diagram-design/assets/example-loop.html | 0 .../assets/example-marimekko-dark.html | 0 .../assets/example-marimekko-full.html | 0 .../assets/example-marimekko.html | 0 .../assets/example-medallion-dark.html | 0 .../assets/example-medallion-full.html | 0 .../assets/example-medallion.html | 0 .../assets/example-nested-dark.html | 0 .../assets/example-nested-full.html | 0 .../diagram-design/assets/example-nested.html | 0 .../assets/example-org-chart-dark.html | 0 .../assets/example-org-chart-full.html | 0 .../assets/example-org-chart.html | 0 .../assets/example-paved-road-animated.html | 0 .../assets/example-polar-dark.html | 0 .../assets/example-polar-full.html | 0 .../diagram-design/assets/example-polar.html | 0 .../assets/example-policy-trace-animated.html | 0 .../assets/example-process-dark.html | 0 .../assets/example-process-full.html | 0 .../assets/example-process.html | 0 .../assets/example-pyramid-dark.html | 0 .../assets/example-pyramid-full.html | 0 .../assets/example-pyramid.html | 0 .../assets/example-quadrant-consultant.html | 0 .../assets/example-quadrant-dark.html | 0 .../assets/example-quadrant-full.html | 0 .../assets/example-quadrant.html | 0 .../assets/example-queue-animated.html | 0 .../assets/example-radar-dark.html | 0 .../assets/example-radar-full.html | 0 .../diagram-design/assets/example-radar.html | 0 .../assets/example-ridgeline-dark.html | 0 .../assets/example-ridgeline-full.html | 0 .../assets/example-ridgeline.html | 0 .../assets/example-sankey-dark.html | 0 .../assets/example-sankey-full.html | 0 .../diagram-design/assets/example-sankey.html | 0 .../assets/example-scatter-dark.html | 0 .../assets/example-scatter-full.html | 0 .../assets/example-scatter.html | 0 .../assets/example-sequence-dark.html | 0 .../assets/example-sequence-full.html | 0 .../assets/example-sequence-oauth-dark.html | 0 .../assets/example-sequence-oauth-full.html | 0 .../assets/example-sequence-oauth.html | 0 .../assets/example-sequence.html | 0 .../assets/example-slopegraph-dark.html | 0 .../assets/example-slopegraph-full.html | 0 .../assets/example-slopegraph.html | 0 .../assets/example-state-dark.html | 0 .../assets/example-state-full.html | 0 .../assets/example-state-lifecycle-dark.html | 0 .../assets/example-state-lifecycle-full.html | 0 .../assets/example-state-lifecycle.html | 0 .../diagram-design/assets/example-state.html | 0 .../assets/example-story-map-dark.html | 0 .../assets/example-story-map-full.html | 0 .../assets/example-story-map.html | 0 .../assets/example-streamgraph-dark.html | 0 .../assets/example-streamgraph-full.html | 0 .../assets/example-streamgraph.html | 0 .../assets/example-swimlane-dark.html | 0 .../assets/example-swimlane-full.html | 0 .../assets/example-swimlane.html | 0 .../assets/example-timeline-dark.html | 0 .../assets/example-timeline-full.html | 0 .../assets/example-timeline.html | 0 ...example-tree-block-decomposition-dark.html | 0 ...example-tree-block-decomposition-full.html | 0 .../example-tree-block-decomposition.html | 0 .../assets/example-tree-dark.html | 0 .../assets/example-tree-full.html | 0 .../diagram-design/assets/example-tree.html | 0 .../assets/example-treemap-dark.html | 0 .../assets/example-treemap-full.html | 0 .../assets/example-treemap.html | 0 .../assets/example-uml-class-dark.html | 0 .../assets/example-uml-class-full.html | 0 .../assets/example-uml-class.html | 0 .../assets/example-venn-dark.html | 0 .../assets/example-venn-full.html | 0 .../diagram-design/assets/example-venn.html | 0 .../assets/example-wardley-dark.html | 0 .../assets/example-wardley-full.html | 0 .../assets/example-wardley.html | 0 .../assets/example-waterfall-dark.html | 0 .../assets/example-waterfall-full.html | 0 .../assets/example-waterfall.html | 0 .../assets/diagram-design/assets/icons.html | 0 .../assets/diagram-design/assets/index.html | 0 .../diagram-design/assets/template-dark.html | 0 .../diagram-design/assets/template-full.html | 0 .../assets/template-motion.html | 0 .../assets/template-terminal.html | 0 .../diagram-design/assets/template.html | 0 .../diagram-design/references/animation.md | 0 .../diagram-design/references/doctor.md | 0 .../references/export-registry.md | 0 .../diagram-design/references/export.md | 0 .../references/import-drawio.md | 0 .../references/import-excalidraw.md | 0 .../references/import-mermaid.md | 0 .../diagram-design/references/onboarding.md | 0 .../diagram-design/references/output-spec.md | 0 .../references/primitive-annotation.md | 0 .../references/primitive-icons.md | 0 .../references/primitive-sketchy.md | 0 .../references/primitive-terminal.md | 0 .../diagram-design/references/profiles.md | 0 .../references/semantic-patterns.md | 0 .../diagram-design/references/style-guide.md | 0 .../references/type-architecture.md | 0 .../diagram-design/references/type-bar.md | 0 .../references/type-data-flow.md | 0 .../references/type-db-schema.md | 0 .../references/type-dependency.md | 0 .../references/type-deployment.md | 0 .../references/type-dp-integration.md | 0 .../references/type-dp-security-matrix.md | 0 .../diagram-design/references/type-er.md | 0 .../references/type-fishbone.md | 0 .../references/type-flowchart.md | 0 .../diagram-design/references/type-gantt.md | 0 .../diagram-design/references/type-heatmap.md | 0 .../references/type-high-level.md | 0 .../references/type-it-state.md | 0 .../diagram-design/references/type-journey.md | 0 .../diagram-design/references/type-kanban.md | 0 .../diagram-design/references/type-layers.md | 0 .../diagram-design/references/type-line.md | 0 .../diagram-design/references/type-loop.md | 0 .../references/type-medallion.md | 0 .../diagram-design/references/type-nested.md | 0 .../references/type-org-chart.md | 0 .../diagram-design/references/type-polar.md | 0 .../diagram-design/references/type-process.md | 0 .../diagram-design/references/type-pyramid.md | 0 .../references/type-quadrant.md | 0 .../diagram-design/references/type-radar.md | 0 .../diagram-design/references/type-sankey.md | 0 .../diagram-design/references/type-scatter.md | 0 .../references/type-sequence.md | 0 .../diagram-design/references/type-state.md | 0 .../references/type-story-map.md | 0 .../references/type-swimlane.md | 0 .../references/type-timeline.md | 0 .../diagram-design/references/type-tree.md | 0 .../diagram-design/references/type-treemap.md | 0 .../references/type-uml-class.md | 0 .../diagram-design/references/type-venn.md | 0 .../diagram-design/references/type-wardley.md | 0 .../references/type-waterfall.md | 0 .../diagram-design/scripts/drawio_extract.py | 0 .../scripts/excalidraw_extract.py | 0 .../diagram-design/scripts/mermaid_extract.py | 0 .../diagram-design/scripts/self_check.py | 0 .../assets/element-picker/SKILL.md | 77 + .../element-picker/chrome-extension/README.md | 65 + .../chrome-extension/background.js | 25 + .../chrome-extension/manifest.json | 30 + .../element-picker/chrome-extension/picker.js | 374 ++ .../assets/element-picker/picker.js | 360 ++ .../assets/element-picker/ui-picker-server.js | 125 + .../assets/video-capture/ATTRIBUTION.md | 0 .../assets/video-capture/SKILL.md | 0 .../references/_留痕/N6-20261016/SKILL.md | 305 ++ .../_留痕/N6-20261016/_crlf-baseline.json | 80 + .../references/stage-delivery/SKILL.md | 385 ++ .../references/execution-runbook.md | 476 ++ .../stage-delivery/scripts/_common.py | 143 + .../stage-delivery/scripts/check_js.py | 110 + .../stage-delivery/scripts/check_skeleton.py | 139 + .../stage-delivery/scripts/selftest_gates.py | 152 + .../references/stage-discovery/SKILL.md | 228 + .../references/stage-proto-doc/SKILL.md | 181 + .../stage-proto-doc/assets/产品文档模板.html | 247 + .../references/doc-area-spec.md | 72 + .../references/doc-language-spec.md | 322 ++ .../references/stage-requirements/SKILL.md | 172 + .../references/create-prd.md | 133 + .../references/state-machine.md | 82 + .../_留痕/N6-补对齐-20261016/SKILL.md | 313 ++ .../N6-补对齐-20261016/_crlf-baseline-D1.json | 26 + .../references/stage-discovery/SKILL.md | 232 + .../references/stage-proto-doc/SKILL.md | 186 + .../stage-requirements/assets/产品规划模板.md | 58 + .../_留痕/N7-返工-20261016/SKILL.md | 313 ++ .../stage-delivery/scripts/_common.py | 166 + .../stage-discovery/references/grill-me.md | 171 + .../references/stage-proto-doc/SKILL.md | 186 + .../stage-proto-doc/assets/产品文档模板.html | 255 + .../references/doc-area-spec.md | 73 + .../references/doc-language-spec.md | 322 ++ .../references/stage-requirements/SKILL.md | 198 + .../N7-返工-20261016/scripts/check_naming.py | 448 ++ ...SKILL-总入口-20261016加element-picker前.md | 314 ++ .../SKILL-总入口-20261016技能级assets前.md | 322 ++ ...L-总入口-20261016改element-picker落点前.md | 322 ++ ...tage-delivery-SKILL-20261016-改自带件前.md | 401 ++ ...e-delivery-SKILL-20261016技能级assets前.md | 401 ++ .../_留痕/stage-delivery/scripts/_common.py | 166 + .../references/_留痕/stage-proto-doc/SKILL.md | 186 + .../stage-proto-doc/assets/产品文档模板.html | 255 + .../references/doc-area-spec.md | 73 + .../references/doc-language-spec.md | 322 ++ ...quirements-SKILL-20261016技能级assets前.md | 198 + .../_留痕/stage-requirements/SKILL.md | 198 + .../references/stage-proto-doc/SKILL.md | 186 + .../references/stage-requirements/SKILL.md | 198 + .../stage-requirements/assets/产品规划模板.md | 58 + .../references/stage-delivery/SKILL.md | 73 +- .../design-system-tiaoyue/SKILL.md | 144 - .../design-system-tiaoyue/assets/brand.json | 231 - .../assets/tokens-dark.css | 155 - .../design-system-tiaoyue/assets/tokens.css | 46 - .../references/capture-notes.md | 51 - .../references/components.md | 499 -- .../references/design-system.html | 1052 ----- .../references/known-conflicts.md | 82 - .../references/library.json | 4113 ----------------- .../references/execution-runbook.md | 51 +- .../references/layouts-tooling.md | 4 +- .../stage-delivery/scripts/_common.py | 128 +- .../stage-delivery/scripts/check_js.py | 8 +- .../stage-delivery/scripts/check_skeleton.py | 14 +- .../stage-delivery/scripts/selftest_gates.py | 11 +- .../references/stage-discovery/SKILL.md | 22 +- ...perseded-competitor-analysis-英文商业版.md | 2 +- .../references/competitor-analysis.md | 4 +- .../stage-discovery/references/grill-me.md | 14 +- .../references/product-strategy.md | 2 +- .../references/usage-scenario.md | 8 +- .../references/user-personas.md | 2 +- .../references/stage-proto-doc/SKILL.md | 61 +- .../stage-proto-doc/assets/产品文档模板.html | 44 +- .../references/doc-area-spec.md | 23 +- .../references/doc-language-spec.md | 2 +- .../references/stage-requirements/SKILL.md | 54 +- .../stage-requirements/assets/产品规划模板.md | 60 + .../references/create-prd.md | 12 +- .../references/state-machine.md | 8 +- product-planning/scripts/check_naming.py | 44 +- product-planning/scripts/check_terms.py | 195 + .../scripts/selftest_product_root.py | 99 + session-mechanism/SKILL.md | 2 +- .../references/06-技能优化规程.md | 12 +- .../references/_留痕/优化-20261016/SKILL.md | 1057 +++++ .../references/06-技能优化规程.md | 106 + session-mechanism/scripts/collabctl.py | 18 +- 336 files changed, 12821 insertions(+), 6621 deletions(-) rename product-planning/{references/stage-delivery => }/assets/design-capture/ATTRIBUTION.md (100%) rename product-planning/{references/stage-delivery => }/assets/design-capture/SKILL.md (100%) rename product-planning/{references/stage-delivery => }/assets/design-capture/scripts/build_style_package.py (100%) rename product-planning/{references/stage-delivery => }/assets/design-capture/scripts/capture_design_system.mjs (100%) rename product-planning/{references/stage-delivery => }/assets/design-capture/vendor/brand-capture.js (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/SKILL.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-architecture-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-architecture-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-architecture.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-bar-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-bar-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-bar.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-beeswarm-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-beeswarm-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-beeswarm.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-bubble-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-bubble-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-bubble.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-bump-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-bump-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-bump.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-data-flow-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-data-flow-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-data-flow.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-datalake-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-datalake-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-datalake.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-db-schema-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-db-schema-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-db-schema.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-dependency-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-dependency-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-dependency.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-deployment-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-deployment-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-deployment.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-dp-integration-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-dp-integration-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-dp-integration.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-dp-security-matrix-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-dp-security-matrix-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-dp-security-matrix.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-er-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-er-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-er.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-fishbone-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-fishbone-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-fishbone.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-flowchart-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-flowchart-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-flowchart.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-gantt-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-gantt-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-gantt.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-heatmap-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-heatmap-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-heatmap.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-high-level-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-high-level-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-high-level-vertical-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-high-level-vertical-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-high-level-vertical.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-high-level.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-import-drawio.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-import-excalidraw.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-import-mermaid.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-it-state-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-it-state-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-it-state.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-journey-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-journey-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-journey.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-kanban-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-kanban-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-kanban.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-layers-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-layers-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-layers.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-line-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-line-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-line.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-loop-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-loop-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-loop-terminal.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-loop.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-marimekko-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-marimekko-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-marimekko.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-medallion-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-medallion-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-medallion.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-nested-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-nested-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-nested.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-org-chart-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-org-chart-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-org-chart.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-paved-road-animated.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-polar-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-polar-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-polar.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-policy-trace-animated.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-process-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-process-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-process.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-pyramid-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-pyramid-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-pyramid.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-quadrant-consultant.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-quadrant-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-quadrant-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-quadrant.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-queue-animated.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-radar-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-radar-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-radar.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-ridgeline-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-ridgeline-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-ridgeline.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-sankey-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-sankey-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-sankey.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-scatter-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-scatter-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-scatter.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-sequence-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-sequence-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-sequence-oauth-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-sequence-oauth-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-sequence-oauth.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-sequence.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-slopegraph-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-slopegraph-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-slopegraph.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-state-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-state-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-state-lifecycle-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-state-lifecycle-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-state-lifecycle.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-state.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-story-map-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-story-map-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-story-map.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-streamgraph-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-streamgraph-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-streamgraph.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-swimlane-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-swimlane-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-swimlane.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-timeline-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-timeline-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-timeline.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-tree-block-decomposition-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-tree-block-decomposition-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-tree-block-decomposition.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-tree-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-tree-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-tree.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-treemap-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-treemap-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-treemap.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-uml-class-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-uml-class-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-uml-class.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-venn-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-venn-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-venn.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-wardley-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-wardley-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-wardley.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-waterfall-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-waterfall-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/example-waterfall.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/icons.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/index.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/template-dark.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/template-full.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/template-motion.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/template-terminal.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/assets/template.html (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/animation.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/doctor.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/export-registry.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/export.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/import-drawio.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/import-excalidraw.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/import-mermaid.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/onboarding.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/output-spec.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/primitive-annotation.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/primitive-icons.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/primitive-sketchy.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/primitive-terminal.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/profiles.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/semantic-patterns.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/style-guide.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-architecture.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-bar.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-data-flow.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-db-schema.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-dependency.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-deployment.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-dp-integration.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-dp-security-matrix.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-er.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-fishbone.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-flowchart.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-gantt.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-heatmap.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-high-level.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-it-state.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-journey.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-kanban.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-layers.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-line.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-loop.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-medallion.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-nested.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-org-chart.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-polar.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-process.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-pyramid.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-quadrant.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-radar.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-sankey.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-scatter.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-sequence.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-state.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-story-map.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-swimlane.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-timeline.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-tree.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-treemap.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-uml-class.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-venn.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-wardley.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/references/type-waterfall.md (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/scripts/drawio_extract.py (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/scripts/excalidraw_extract.py (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/scripts/mermaid_extract.py (100%) rename product-planning/{references/stage-requirements => }/assets/diagram-design/scripts/self_check.py (100%) create mode 100644 product-planning/assets/element-picker/SKILL.md create mode 100644 product-planning/assets/element-picker/chrome-extension/README.md create mode 100644 product-planning/assets/element-picker/chrome-extension/background.js create mode 100644 product-planning/assets/element-picker/chrome-extension/manifest.json create mode 100644 product-planning/assets/element-picker/chrome-extension/picker.js create mode 100644 product-planning/assets/element-picker/picker.js create mode 100644 product-planning/assets/element-picker/ui-picker-server.js rename product-planning/{references/stage-delivery => }/assets/video-capture/ATTRIBUTION.md (100%) rename product-planning/{references/stage-delivery => }/assets/video-capture/SKILL.md (100%) create mode 100644 product-planning/references/_留痕/N6-20261016/SKILL.md create mode 100644 product-planning/references/_留痕/N6-20261016/_crlf-baseline.json create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-delivery/SKILL.md create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-delivery/references/execution-runbook.md create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-delivery/scripts/_common.py create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-delivery/scripts/check_js.py create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-delivery/scripts/check_skeleton.py create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-delivery/scripts/selftest_gates.py create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-discovery/SKILL.md create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-proto-doc/SKILL.md create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-proto-doc/assets/产品文档模板.html create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-proto-doc/references/doc-area-spec.md create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-proto-doc/references/doc-language-spec.md create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-requirements/SKILL.md create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-requirements/references/create-prd.md create mode 100644 product-planning/references/_留痕/N6-20261016/references/stage-requirements/references/state-machine.md create mode 100644 product-planning/references/_留痕/N6-补对齐-20261016/SKILL.md create mode 100644 product-planning/references/_留痕/N6-补对齐-20261016/_crlf-baseline-D1.json create mode 100644 product-planning/references/_留痕/N6-补对齐-20261016/references/stage-discovery/SKILL.md create mode 100644 product-planning/references/_留痕/N6-补对齐-20261016/references/stage-proto-doc/SKILL.md create mode 100644 product-planning/references/_留痕/N6-补对齐-20261016/references/stage-requirements/assets/产品规划模板.md create mode 100644 product-planning/references/_留痕/N7-返工-20261016/SKILL.md create mode 100644 product-planning/references/_留痕/N7-返工-20261016/references/stage-delivery/scripts/_common.py create mode 100644 product-planning/references/_留痕/N7-返工-20261016/references/stage-discovery/references/grill-me.md create mode 100644 product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/SKILL.md create mode 100644 product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/assets/产品文档模板.html create mode 100644 product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/references/doc-area-spec.md create mode 100644 product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/references/doc-language-spec.md create mode 100644 product-planning/references/_留痕/N7-返工-20261016/references/stage-requirements/SKILL.md create mode 100644 product-planning/references/_留痕/N7-返工-20261016/scripts/check_naming.py create mode 100644 product-planning/references/_留痕/SKILL-总入口-20261016加element-picker前.md create mode 100644 product-planning/references/_留痕/SKILL-总入口-20261016技能级assets前.md create mode 100644 product-planning/references/_留痕/SKILL-总入口-20261016改element-picker落点前.md create mode 100644 product-planning/references/_留痕/stage-delivery-SKILL-20261016-改自带件前.md create mode 100644 product-planning/references/_留痕/stage-delivery-SKILL-20261016技能级assets前.md create mode 100644 product-planning/references/_留痕/stage-delivery/scripts/_common.py create mode 100644 product-planning/references/_留痕/stage-proto-doc/SKILL.md create mode 100644 product-planning/references/_留痕/stage-proto-doc/assets/产品文档模板.html create mode 100644 product-planning/references/_留痕/stage-proto-doc/references/doc-area-spec.md create mode 100644 product-planning/references/_留痕/stage-proto-doc/references/doc-language-spec.md create mode 100644 product-planning/references/_留痕/stage-requirements-SKILL-20261016技能级assets前.md create mode 100644 product-planning/references/_留痕/stage-requirements/SKILL.md create mode 100644 product-planning/references/_留痕/优化-20261016/references/stage-proto-doc/SKILL.md create mode 100644 product-planning/references/_留痕/优化-20261016/references/stage-requirements/SKILL.md create mode 100644 product-planning/references/_留痕/优化-20261016/references/stage-requirements/assets/产品规划模板.md delete mode 100644 product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/SKILL.md delete mode 100644 product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/assets/brand.json delete mode 100644 product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/assets/tokens-dark.css delete mode 100644 product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/assets/tokens.css delete mode 100644 product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/references/capture-notes.md delete mode 100644 product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/references/components.md delete mode 100644 product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/references/design-system.html delete mode 100644 product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/references/known-conflicts.md delete mode 100644 product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/references/library.json create mode 100644 product-planning/references/stage-requirements/assets/产品规划模板.md create mode 100644 product-planning/scripts/check_terms.py create mode 100644 product-planning/scripts/selftest_product_root.py create mode 100644 session-mechanism/references/_留痕/优化-20261016/SKILL.md create mode 100644 session-mechanism/references/_留痕/优化-20261016/references/06-技能优化规程.md diff --git a/.gitignore b/.gitignore index 7630ae7..97f5e03 100644 --- a/.gitignore +++ b/.gitignore @@ -95,3 +95,13 @@ uv.lock node_modules/ # 本机部署副本与状态（`.workbuddy/` 是**工作区**的东西，⛔ 不该出现在技能库） .workbuddy/ + +# 🔴 2026-10-16 用户令：「design-system-tiaoyue」**整个目录不入库**（磁盘保留、照常用）。 +# 判据＝体积（14 MB：真机组件库 13 MB ＋ 整站样式合并 1.1 MB）＋ 可再采（CDP 直连真机重采即可）。 +# 已入库的 9 个文件用 `git rm -r --cached` 移出（⛔ 磁盘保留）。 +# ⚠️ 取仓后③段 D1 定调拿不到自带套 ⇒ 按 `product-planning/references/stage-delivery/SKILL.md` §供给 另取或重采。 +# 🔴 本行必须留在文件末尾：白名单是「先 /* 全挡、再逐个放行」，否则 `!/product-planning/` 会把它放回来。 +/product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/ + +# 运行期存档（`element-picker` 拾取器每次点「确认」都会往这里追加；服务自己会建目录，不入库） +/product-planning/assets/element-picker/marks/ diff --git a/product-planning/SKILL.md b/product-planning/SKILL.md index 8c5a674..47fb066 100644 --- a/product-planning/SKILL.md +++ b/product-planning/SKILL.md @@ -17,10 +17,10 @@ description: 产品规划总入口（唯一入口），四段式调度：① 产 | 段 | 回答的问题 | 子步 | 调用 | 产出物 | |---|---|---|---|---| -| **① 产品需求** | 要做的东西凭什么成立：什么问题、为谁、为什么值得做 | 1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景 | `stage-discovery` | `docs/pm/<项目>/research/*`。其中 1b 交两种体例：`research/1b-竞品分析.md`（汇总对比）＋ `research/1b-独立分析/<竞品名>.md`（独立分析） | -| **② 产品功能** | 要做哪些功能、什么不做、长成什么骨架 | 2a 产品功能 / 2b 界面布局 | `stage-requirements` | `docs/pm/<项目>/prd/2a-产品功能.md` 与 `prd/2b-界面布局.md`（两份） | -| **③ 界面交互** | 长什么样、怎么操作 | 3a 视觉规范 / 3b 原型 / 3c GPT参考版 / 3d 审查打磨 | `stage-delivery` | `docs/pm/<项目>/DESIGN.md`、`docs/pm/<项目>/ui/*.html`、`docs/pm/<项目>/ui/3c-GPT参考版.md` | -| **④ 原型说明文档** | 现有原型怎么用、每条功能落在哪个页面、坏了怎样、怎么核对（文档按六节铺：页面结构 → 功能清单 → 使用场景 → 操作流程 → 跨页与界面状态 → 待确认与偏离） | 4a 场景盘点 / 4b 说明区 / 4c 演示引导（可选） | `stage-proto-doc` | 原型内嵌说明区 ＋ 独立产品文档 `docs/pm/<项目>/ui/产品文档.html`（两份共用同一套 P 页面／S 场景／F 功能／J 二级功能编号） | +| **① 产品需求** | 要做的东西凭什么成立：什么问题、为谁、为什么值得做 | 1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景 | `stage-discovery` | `产品规划/research/*`。其中 1b 交两种体例：`research/1b-竞品分析.md`（汇总对比）＋ `research/1b-独立分析/<竞品名>.md`（独立分析） | +| **② 产品功能** | 要做哪些功能、什么不做、长成什么骨架 | 2a 产品功能 / 2b 界面布局 | `stage-requirements` | `产品规划/prd/2a-产品功能.md` 与 `产品规划/prd/2b-界面布局.md`（两份） | +| **③ 界面交互** | 长什么样、怎么操作 | 3a 视觉规范 / 3b 原型 / 3c GPT参考版 / 3d 审查打磨 | `stage-delivery` | `产品原型/designs/DESIGN.md`、`产品原型/pages/*.html`、`产品原型/designs/3c-GPT参考版.md` | +| **④ 原型说明文档** | 现有原型怎么用、每条功能落在哪个页面、坏了怎样、怎么核对（文档按七节铺：原型地址 → 页面结构 → 功能清单 → 使用场景 → 操作流程 → 页面导航 → 原型状态取值） | 4a 场景盘点 / 4b 说明区 / 4c 演示引导（可选） | `stage-proto-doc` | 原型内嵌说明区 ＋ 独立产品文档 `产品原型/pages/<产品项目名>.html`（两份共用同一套 P 页面／S 场景／F 功能／J 二级功能编号） | 四段只通过落盘文件耦合。段间交接口如下，这是唯一的契约，越界即失效： @@ -35,13 +35,13 @@ description: 产品规划总入口（唯一入口），四段式调度：① 产 > ②→③ 最容易搞坏。旧病灶：②段说「必须能读到」，③段读成「必须常驻主屏」，五类信息就全铺一屏成了信息墙。分档表把「读到」明确成「一次点击内可达」，防的就是这句歧义。骨架是灰块（有哪些块、什么顺序），③段给的是视觉与交互实现（排版、点哪有什么反馈、空态、响应式）。两件事各管一维，③段不会退化成照抄。 > 四段各占一个词，互不共用（2026-10-02 定）：产品 / 功能 / 界面 / 说明。改段名前先对照这张表；两个段名里出现同一个词，边界一定在漂。旧名「调研与方案 / 需求与结构」都含「需求」，③段旧名里的「交付」是三段共有的属性，都属名实不符，已改。 -> 🔴 **④段的沿革（2026-10-14 → 10-15）**：10-14 按用户令删掉**旧版**④段 —— 旧做法是往原型 HTML 注入说明区注解层（状态 → 场景 → 从左到右流程图 → 功能作用/输入边界/异常情况 三段 → 逐步骤演示引导），实测没法用，整段连方法论一并撤掉。10-15 用备份里的**新版**④段装上：改成「解释与记录现有原型」，交**两份产物**（原型内嵌说明区 ＋ 独立产品文档 `docs/pm/<项目>/ui/产品文档.html`），内容先按四块＋附录铺，随后整套同步成**六节**（页面结构／功能清单／使用场景／操作流程／跨页与界面状态／待确认与偏离），编号改用 P 页面／S 场景／F 功能／J 二级功能，并带一份现成模板 `references/stage-proto-doc/assets/产品文档模板.html`。判据正文在 `references/stage-proto-doc/`，⛔ 旧版那套（状态轴、三段必填、逐步骤演示）不再使用。 +> 🔴 **④段的沿革（2026-10-14 → 10-15）**：10-14 按用户令删掉**旧版**④段 —— 旧做法是往原型 HTML 注入说明区注解层（状态 → 场景 → 从左到右流程图 → 功能作用/输入边界/异常情况 三段 → 逐步骤演示引导），实测没法用，整段连方法论一并撤掉。10-15 用备份里的**新版**④段装上：改成「解释与记录现有原型」，交**两份产物**（原型内嵌说明区 ＋ 独立产品文档 `产品原型/pages/<产品项目名>.html`），内容先按四块＋附录铺，随后整套同步成**七节**（原型地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值），编号改用 P 页面／S 场景／F 功能／J 二级功能，并带一份现成模板 `references/stage-proto-doc/assets/产品文档模板.html`。判据正文在 `references/stage-proto-doc/`，⛔ 旧版那套（状态轴、三段必填、逐步骤演示）不再使用。 > ①叫「产品需求」不叫「需求调研」：该段产出 `research/1a-需求文档.md`、`1b-竞品分析.md`、`1c-用户画像.md`，也产出 `1d-产品策略.md`、`1e-使用场景.md`，「调研」二字盖不住后半截。 > ⭐ 1b 是①段唯一交两种体例的子步：独立分析体 `research/1b-独立分析/<竞品名>.md`（竞品池每一个一份），汇总对比体 `research/1b-竞品分析.md`（恒一份）。职责边界与定案原话见 `references/stage-discovery/references/competitor-analysis.md` §0.4。 ⭐ `grill-me` 全场只有①段一份（2026-10-06 用户定案）：①段那份按 A / B 两节提问，火力点划分、节次归属与定案原话见 `references/stage-discovery/references/grill-me.md` —— ⛔ 本入口不复述。B 节结论落进 `research/1a-需求文档.md`。 -⭐ ②段产出两份（2026-10-06 收窄，2026-10-07 定为两份）：`prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 ＋ 状态流转）与 `prd/2b-界面布局.md`（页面关系 ＋ 页面内板块布局）。定案原话与理由见 `references/stage-requirements/SKILL.md` 开头。 +⭐ ②段产出两份（2026-10-06 收窄，2026-10-07 定为两份）：`产品规划/prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 ＋ 状态流转）与 `产品规划/prd/2b-界面布局.md`（页面关系 ＋ 页面内板块布局）。定案原话与理由见 `references/stage-requirements/SKILL.md` 开头。 （交接口反转前的口径、②段收窄前的产出清单与去向 → `references/_留痕/③段与总入口-旧口径.md`） @@ -49,15 +49,26 @@ description: 产品规划总入口（唯一入口），四段式调度：① 产 段内的子步顺序、方法论文档、硬约束、完成标准，都在各段自己的 `SKILL.md` 与 `references/` 里。 -①段 1a 需求文档：全程最先做，且只做一次。用 grill-me 与用户互动，产出 `docs/pm/<项目>/research/1a-需求文档.md`（开头写清做什么 / 为谁 / 不做什么，往下是决策表）。 +①段 1a 需求文档：全程最先做，且只做一次。用 grill-me 与用户互动，产出 `产品规划/research/1a-需求文档.md`（开头写清做什么 / 为谁 / 不做什么，往下是决策表）。 ## 项目与路径约定（单一真源） -> 四段全部遵守本节。各段 `SKILL.md` 与 `references/` 里出现 `docs/pm/...` 时，`<项目>` 一律指本节定义的 slug。 +> 四段全部遵守本节。**产品根** ＝ 同时含 `产品规划/` 与 `产品原型/` 的那一层目录（例 `<工作区>/项目/script-shortvideo/`）。各段 `SKILL.md` 与 `references/` 里的 `产品规划/...`、`产品原型/...` 一律**相对产品根**读。 -### `<项目>` 是什么 +### 目录长什么样 -项目 slug 用小写字母、数字、连字符（例 `my-tool`、`video-canvas`）。它就是 `docs/pm/<项目>/` 这一层的目录名，一个字都不能差；各段产物都挂在它下面 —— ①段 `research/`、②段 `prd/`、③段与④段 `ui/`、跨段 `专题/`。 +工作区顶层只放 `项目/`｜`调研/`｜`复盘/`（外加机制自己的 `tmp/`、`交付物/`、`执行会话/`、`.workbuddy/`、`.registry/`）。 + +`项目/` 下是**产品文件夹**，一个产品一层，目录名就是产品 slug（小写字母、数字、连字符，例 `my-tool`、`script-shortvideo`）—— 这个目录就是**产品根**。产品根下三个落点： + +| 根 | 路径 | 装什么 | +|---|---|---| +| 🔴 **文档根** | `产品规划/` | ①段 `research/`（`1a`~`1e`）、②段 `prd/`（`2a-产品功能.md` ／ `2b-界面布局.md`）、跨段 `专题/` | +| 🔴 **设计根** | `产品原型/designs/` | ③段 `DESIGN.md` ＋ `3c-GPT参考版.md` ＋ 3d 审查留痕件 ＋ 截图 `_gate_shots/` | +| 🔴 **页面根** | `产品原型/pages/` | ③段原型 `*.html` ＋ ④段独立产品文档 `<产品项目名>.html` ＋ 页面用静态资源 | + +⚠️ **②段 prd 归文档根**，⛔ 不跟③段一起搬 —— 它与①段 `research/` 同根，③段的机检脚本也按 `产品规划/prd/2b-*.md` 去定位它（`find_doc`）。⛔ 已废的那层 `ui/` 子目录不要再写进任何判据。 +⚠️ **原型页面不放在设计根**（放在页面根 `产品原型/pages/`）：③段的机检脚本按 `产品原型/pages/*.html` 找原型（`find_proto`）。⛔ 原型 HTML 一律落页面根，设计根只留规范与参考件。 ### slug 怎么定（按序取第一个成立的） @@ -65,26 +76,28 @@ description: 产品规划总入口（唯一入口），四段式调度：① 产 |---|---|---| | 1 | 用户在当前会话里明确说了项目名 | 该名字 slug 化 | | 2 | `.registry/current-project` 存在且非空 | 其内容 | -| 3 | `docs/pm/` 下恰有一个非 `_` 开头的目录 | 该目录名 | +| 3 | `项目/` 下恰有一个非 `_` 开头的目录 | 该目录名（＝产品根名） | | 4 | 以上都不成立 | 停下问用户 | -写任何文件之前先核对：目标路径里的 `<项目>` 段与按上表得出的 slug 是否一致。不一致就停下说明，不要「先写了再说」——猜错会把产物写进别的项目，事后极难拆干净。 +写任何文件之前先核对：目标路径里产品根那一段的目录名与按上表得出的 slug 是否一致。不一致就停下说明，不要「先写了再说」——猜错会把产物写进别的项目，事后极难拆干净。 ### 产物落哪 | 段 | 路径 | |---|---| -| ① 产品需求 | `docs/pm/<项目>/research/` | -| ② | `docs/pm/<项目>/prd/` | -| ③ | `docs/pm/<项目>/DESIGN.md`、`docs/pm/<项目>/ui/*.html`、`docs/pm/<项目>/ui/3c-GPT参考版.md` | -| ④ | 原型内嵌说明区（写进 `docs/pm/<项目>/ui/*.html` 自身）＋ 独立产品文档 `docs/pm/<项目>/ui/产品文档.html` | +| ① 产品需求 | `产品规划/research/` | +| ② | `产品规划/prd/` | +| ③ | `产品原型/designs/DESIGN.md`、`产品原型/pages/*.html`、`产品原型/designs/3c-GPT参考版.md` | +| ④ | 原型内嵌说明区（写进 `产品原型/pages/*.html` 自身）＋ 独立产品文档 `产品原型/pages/<产品项目名>.html` | ### 文档的两态：当前版与过期版 用户令（2026-10-11 逐字）：「**应该有文件夹 专门归档过期文档， 当前文档 统一放在方案文件夹中**」。 -🔴 **方案文件夹** ＝ `docs/pm/<项目>/` 这一层 —— 它下面放的全是**当前权威版**：①段 `research/`、②段 `prd/`、③段 `ui/`、跨段 `专题/`，另加一份 `索引-当前权威版.md` 当入口。 -🔴 **归档文件夹** ＝ `docs/pm/<项目>/归档-过期版/` —— 被顶替下来的旧版全放这里，命名 `<原名>__<来源目标短哈希>.<扩展名>`（例 `2b-界面布局-新版__fc471a.md`）。 +🔴 **方案文件夹** ＝ `产品规划/` 这一层 —— 它下面放的全是**当前权威版**：①段 `research/`、②段 `prd/`、跨段 `专题/`，另加一份 `索引-当前权威版.md` 当入口。 + ⚠️ ③段与④段的产物**不在**文档根 —— 规范类在设计根 `产品原型/designs/`、页面类在页面根 `产品原型/pages/`（见上「产物落哪」）。⛔ 别按老口径去文档根下的 `ui/` 子目录找原型（那层已废）。 +🔴 **归档文件夹** ＝ `产品规划/归档-过期版/` —— 被顶替下来的旧版全放这里，命名 `<原名>__<来源目标短哈希>.<扩展名>`（例 `2b-界面布局-新版__fc471a.md`）。 +🔴 **设计根与页面根也各有归档文件夹** ＝ `产品原型/designs/归档-过期版/` 与 `产品原型/pages/归档-过期版/` —— 前者收被替换下来的设计规范与参考件，后者收被替换下来的原型页面与历史产品文档；命名带版本号或日期以便分辨。 **每个目标收口时做四步**： 1、本目标的权威文档**覆盖**方案文件夹里对应的那一份。 @@ -92,13 +105,13 @@ description: 产品规划总入口（唯一入口），四段式调度：① 产 3、更新 `索引-当前权威版.md` 里对应行的大小与日期。 4、执行区（`执行会话/目标-*/` 这类过程目录）里的原件**保留** —— 它既是过程留痕，也是台账 `artifact` 指向的地方，搬空会让回查断链。 -**为什么要有这条**（避坑依据 · 2026-10-11 实测）：同一个 `2a-产品功能` 在 6 个目标目录里各有版本、`2b` 有 7 个，光看文件名与字节数分不出谁新；而 `docs/pm/` 下早先那次归档又停在旧版（`2b` 只 52 256 B，最新已是 52 643 B）⇒ 用户问「很多新老方案都在文件夹中，后续根据方案细化产品界面，如何找得到对应的方案」。判断某份文档的当前版，**只看方案文件夹**；问「当时为什么这么定」才去归档文件夹翻。 +**为什么要有这条**（避坑依据 · 2026-10-11 实测）：同一个 `2a-产品功能` 在 6 个目标目录里各有版本、`2b` 有 7 个，光看文件名与字节数分不出谁新；而 `产品规划/` 下早先那次归档又停在旧版（`2b` 只 52 256 B，最新已是 52 643 B）⇒ 用户问「很多新老方案都在文件夹中，后续根据方案细化产品界面，如何找得到对应的方案」。判断某份文档的当前版，**只看方案文件夹**；问「当时为什么这么定」才去归档文件夹翻。 -### DESIGN.md 为什么在项目目录、不在仓库根 +### DESIGN.md 为什么在产品根、不在工作区根 -`DESIGN.md` 是③段的绑定视觉规范，一个项目一份，③段按当前项目的 slug 去读它。仓库根只能放一份，多项目会互相覆盖，所以一律放 `docs/pm/<项目>/DESIGN.md`。 +`DESIGN.md` 是③段的绑定视觉规范，一个产品一份，③段按产品 slug 去读它。工作区根只能放一份，多产品会互相覆盖，所以一律放 `产品原型/designs/DESIGN.md`。 -推论（硬规则）：读 `DESIGN.md` 时，路径必须由本节定义的 `<项目>` slug 拼出，不许用「当前工作目录碰巧有 DESIGN.md」这类推断。仓库根不放任何项目的 `DESIGN.md`。 +推论（硬规则）：读 `DESIGN.md` 时，路径必须由本节定义的**产品根**拼出，不许用「当前工作目录碰巧有 DESIGN.md」这类推断。工作区根不放任何产品的 `DESIGN.md`。 ## 工具选择规则（防止选错，最重要的一节） @@ -128,18 +141,21 @@ DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec ## 可调用工具（自然语言触发） -> 两个独立工具，按用户说法直接触发，产物落项目目录。`design-capture` 随③段携带（装在③段 `references/stage-delivery/assets/` 下）；`video-capture` 2026-10-11 已独立成全局技能（装在**技能根**下的 `video-capture/`），跨段复用。两者都不单独成段。 +> 三个独立工具，按用户说法直接触发，产物落项目目录。它们都装在**技能级工具箱** `assets/` 下（相对本技能包根，各段共用）：`assets/design-capture/`、`assets/element-picker/`；工具箱里另有 `assets/diagram-design/`（②④段画图用）与 `assets/video-capture/`（只剩交接说明）。三个触发式工具都不单独成段；只有 `video-capture` 的**实体**在 2026-10-11 独立成了全局技能（装在**技能根**下），跨段跨项目复用。 + +> 🔴 本技能包里有**两处**都叫 `assets/`，别混：**技能级工具箱** `assets/<工具名>/`（相对本技能包根，各段共用）与**段内资产** `references/stage-*/assets/`（只归那一段）。凡引**工具**，一律写「技能级 `assets/<工具名>/`」；引**本段自己的资产**时可直接写 `assets/...`。 | 用户说 | 触发工具 | 做什么 | 产物 | |---|---|---|---| | 「分析 XXX 视频」「把这个视频抽帧」「拆一下这条视频的画面」 | 全局技能 `video-capture` | 取视频（本地文件 / 直链 URL / 平台页经浏览器下到本地）＋ 抽帧（双因素 ＋ 首尾 ＋ 补帧） | 关键帧 `c_<序号>_<真实秒数>s.jpg` ＋ `frame_times.json`（供①竞品分析、③视觉参考） | -| 「获取 XXX 网站的设计风格」「抓这个网站的风格/组件/配色」 | `stage-delivery/assets/design-capture/` | 抓网页设计系统（色彩 / 排版 / 组件），生成样式模板 | 一套 `design-system-<名>/`（与 `design-system-tiaoyue` 同构，可直接被③段 D1 选用） | +| 「获取 XXX 网站的设计风格」「抓这个网站的风格/组件/配色」 | 技能级 `assets/design-capture/` | 抓网页设计系统（色彩 / 排版 / 组件），生成样式模板 | 一套 `design-system-<名>/`（与 `design-system-tiaoyue` 同构，可直接被③段 D1 选用） | +| 「选中这个组件」「把这个元素的位置给你」「改这个页面的样式」「这个按钮在哪」 | 技能级 `assets/element-picker/` | 在浏览器里点选任意组件，取出它的 CSS 选择器与所属网页，交给 AI 定位源码改样式 | 剪贴板两行（`选择器：…` / `网页：…`）＋ 存档 `marks/_ui-marks.json`（含文本 / class / 属性 / 尺寸 / 关键样式 / HTML 片段） | -两者都独立可单跑：`video-capture` 只依赖 `ffmpeg`（权威件＝全局技能 `video-capture`；原 `stage-delivery/assets/video-capture/` 只留交接说明，脚本迁至 `references/_留痕/video-capture-已独立-20261011/` 留档）；`design-capture` 只依赖本机 Chrome（CDP）＋ `vendor/` 里搬运的抽取脚本，不需要任何外部服务在场。用法与边界见各自 `SKILL.md`，来源与署名见各自 `ATTRIBUTION.md`。 +三者都独立可单跑：`video-capture` 只依赖 `ffmpeg`（权威件＝全局技能 `video-capture`；原 `assets/video-capture/` 只留交接说明，脚本迁至 `references/_留痕/video-capture-已独立-20261011/` 留档）；`design-capture` 只依赖本机 Chrome（CDP）＋ `vendor/` 里搬运的抽取脚本，不需要任何外部服务在场；`element-picker` 只依赖 Node 标准库起一个本地服务（默认 8890，扩展那一路装一次即对所有网页可用）。用法与边界见各自 `SKILL.md`（第三方来源与署名见各自的 `ATTRIBUTION.md`）。 -触发时机：①②段拆竞品视频用全局技能 `video-capture`；③段要新建样式或拆参考站用 `design-capture`。 +触发时机：①②段拆竞品视频用全局技能 `video-capture`；③段要新建样式或拆参考站用 `design-capture`；③段以及任何"用户指着一个组件说改这里"的场合用 `element-picker`。 -两个工具都只做合规最小集：不抓平台页内视频，不调付费接口；抽取结果须先目视比对再采用。 +两个抓取类工具（`video-capture`、`design-capture`）都只做合规最小集：不抓平台页内视频，不调付费接口；抽取结果须先目视比对再采用。`element-picker` 不抓取任何数据，只读当前页面自身的 DOM、把结果落在本地文件。 ## 进入方式 @@ -154,9 +170,9 @@ DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec 「只调一段」成立的原因：四段之间只通过落盘文件耦合，没有隐式状态。 -- ②只读 `docs/pm/<项目>/research/*`；缺失时标注 `【假设】`继续，不催促回补① -- ③只读 `docs/pm/<项目>/prd/*`；缺失时同样标 `【假设】`继续 -- ④只读 `docs/pm/<项目>/ui/*.html`（界面事实的唯一依据），另按需读 `docs/pm/<项目>/prd/*` 与 `research/1a-需求文档.md` 定业务意图；缺失时标 `【假设】`继续，并在段末偏离单里写明 +- ②只读 `产品规划/research/*`；缺失时标注 `【假设】`继续，不催促回补① +- ③只读 `产品规划/prd/*`；缺失时同样标 `【假设】`继续 +- ④只读 `产品原型/pages/*.html`（界面事实的唯一依据），另按需读 `产品规划/prd/*` 与 `research/1a-需求文档.md` 定业务意图；缺失时标 `【假设】`继续，并在段末偏离单里写明 ## 执行规则 @@ -186,13 +202,13 @@ DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec - 声明制（全段适用，不止③段）：开工前、每进一个子段或子步、每处偏离，都要声明三件事——当前在哪、依据哪个文件的哪一节、产出落哪；偏离当场写明原因与影响，段末附偏离单。不许静默偏离。实测踩过的坑：③段 3b 交付了原型却没走当时声明的主流程、没读依据文件，也没当场说，用户追问「基于哪个 skill」才知道。 - 不做八股：不介绍方法论来源，不列人名，不复述框架历史，直接给结论。 - ⭐ 内容准则：一切落盘文字都要先过「说人话」这一关（2026-10-07 用户定案，同日扩大到规则文件）。用户原话：「当作第一步 和 第二步 生成文档时 必须遵循的内容准则」「不管是写规则 还是 写文档 都要严格按照说人话的技能去执行」。 - - 适用面两类都算，只改产出不改规则等于半改。一是产出文档：`research/1a-需求文档.md` 到 `1e-使用场景.md`（5 份）、`research/1b-独立分析/`（独立分析体）、`prd/2a-产品功能.md` 与 `prd/2b-界面布局.md`（2 份）。二是规则本身：本技能包内的一切落盘文字，`SKILL.md`、`references/**`、模板与清单。 + - 适用面两类都算，只改产出不改规则等于半改。一是产出文档：`research/1a-需求文档.md` 到 `1e-使用场景.md`（5 份）、`research/1b-独立分析/`（独立分析体）、`产品规划/prd/2a-产品功能.md` 与 `产品规划/prd/2b-界面布局.md`（2 份）。二是规则本身：本技能包内的一切落盘文字，`SKILL.md`、`references/**`、模板与清单。 - 判据来源（单一可信源，本文件不复述模式清单）：**只有 `humanizer` 一份，且只用它的英文正式目录** —— `<技能根>/humanizer/references/patterns.md` 的 **P1–P55**（内容 8／语言与风格 10／沟通 3／填充与模糊 9／新兴 13／工艺与取证 12）。另有 5 种口吻档（casual / professional / technical / warm / blunt）。 - 🔴 **判据一律用英文目录（2026-10-15 用户令）**：中文附录 `patterns.zh.md`（ZH1–ZH15）**只作参考线索，⛔ 不作判据** —— 作者自标「实验性、未经中文母语写手校验、不应被当作已验证的规则」。原中文版 `humanizer-zh` 的 24 条与五维 50 分表随该技能删除一并停用作废。 - 门槛（2026-10-15 改）： · **英文产出**：可读 `--score` 的 0–100 AI 痕迹密度分（越低越像人；上游 pre-commit 的拦截线是 40），本包不设硬阈值，分数写进段末报告。 · **中文产出**：⛔ 不采信自动分数 —— 该打分器按 `[.!?]` 切句、按 `[a-z0-9]` 切词，中文 `。！？` 不切句、汉字零词，分数实际在测「文件里有多少拉丁字符」（实测：同一段中文把 `。` 换成 `. ` 分数不变；零拉丁字符的中文直接判 `No text`）。改按 **P1–P55 逐条人工对照**，再跑 `--check-facts` 保真（它只抽数字／日期／版本／URL／路径／标识符，中文同形可用）。对照结果与事实存活数写进段末报告，命中项不对完不许落盘。 - - ⛔ 取不到判据来源时（2026-10-08 补）：两份技能都不在位或读不到 ⇒ **不许凭感觉判「这条够人话」**。在段末报告与 `3d-审查报告.md` 里明写「无判据来源，本项未判」，按与 §供给·工艺数值判据 的「证据缺口」同一口径处理。 + - ⛔ 取不到判据来源时（2026-10-08 补）：两份技能都不在位或读不到 ⇒ **不许凭感觉判「这条够人话」**。在段末报告与 3d 审查留痕件（`3d-审查报告.md` 或 `DESIGN.md` 审查节）里明写「无判据来源，本项未判」，按与 §供给·工艺数值判据 的「证据缺口」同一口径处理。 - 五条核心原则（2026-10-15 起**就地固化在本包**；原引自已删除的 `humanizer-zh`《核心规则速查》，英文版 `humanizer` 的 Quick reference 没有等价条目，故不再指向外部）：删填充短语（开场白、强调性拐杖词）；打破公式结构（二元对比、戏剧性分段、修辞性设置）；变化节奏（长短交错，两项优于三项，段尾多样）；信任读者（直接陈述事实，跳过软化、辩解、手把手引导）；删金句（读起来像可引用的话，就重写它）。 - 🔴 **适用面要划清（2026-10-15 排查后立）**：本包只取这份技能里**「去 AI 味」那一半**，⛔ 不取**「注入个性」那一半**。 取这些：英文模式目录 `references/patterns.md` 的 P1–P55、就地固化的五条核心原则、禁用清单。 @@ -231,7 +247,7 @@ DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec - 图要**表达结构或流程**（二选一或兼具）—— 一张图看完就知道「由哪几块组成、怎么连起来」或「一件事分几步走」；⛔ 不做纯装饰性配图。 - 图表达这份文档**覆盖的东西之间的关系**，按段定画什么： · ①段（`research/` 五份）—— 画对象与流向：为谁解决什么、信息从哪来到哪去。 - · ②段（`prd/` 两份）—— 画页面骨架：有哪几页、每页几个板块、跨页关系怎么走。 + · ②段（文档根 `产品规划/prd/` 两份）—— 画页面骨架：有哪几页、每页几个板块、跨页关系怎么走。 · ③段（`ui/` 下的产物与 `DESIGN.md`）—— 画页面结构与操作动线：用户办成一件事实际经过哪几页、每页做什么、哪里要来回跳。 · ④段（产品文档）—— 画页面结构图（各页面与其下的功能编号）＋ 用户路径：各场景怎么串起来。 - 画图用 `diagram-design`，⛔ 不手写 Mermaid（判据见「工具选择规则」那张表）。 @@ -283,10 +299,13 @@ DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec ## 改名 / 改供给后的自检 ```bash -python scripts/check_naming.py --ws <工作区> +python scripts/check_naming.py --ws <工作区或产品根> +python scripts/selftest_product_root.py ``` -它查四段段名与子步名在「总入口 ↔ 各段 `SKILL.md` ↔ 各段 `references/`」之间有没有漂，包括 H1 与子步表是否一致、总入口子步列有没有漏项、runbook 必读表有没有引用已移除的资产、两份副本是否一致。纯静态比对，不需要渲染，不需要外部依赖。 +`check_naming.py` 查四段段名与子步名在「总入口 ↔ 各段 `SKILL.md` ↔ 各段 `references/`」之间有没有漂，包括 H1 与子步表是否一致、总入口子步列有没有漏项、runbook 必读表有没有引用已移除的资产、两份副本是否一致；顺带按 `--ws` 认出的**产品根**扫 ①②段产出白名单。纯静态比对，不需要渲染，不需要外部依赖。 + +`selftest_product_root.py` 只验一件事：**产品根认得对不对**（造临时夹具，⛔ 不碰真实工作区）。三条路都要成立：单产品时给工作区根 / 给产品根本身 / 从子目录向上都认得出同一层；多产品又没有 `.registry/current-project` 指针时**返回空**（⛔ 不猜、不随手拿第一个，让模型停下来问用户）。认错产品根会把产物写进别的产品目录，事后极难拆干净，所以这条单独立测。 为什么必须有它：实测当天漏过两次，当时没有任何门禁会报错。 diff --git a/product-planning/references/stage-delivery/assets/design-capture/ATTRIBUTION.md b/product-planning/assets/design-capture/ATTRIBUTION.md similarity index 100% rename from product-planning/references/stage-delivery/assets/design-capture/ATTRIBUTION.md rename to product-planning/assets/design-capture/ATTRIBUTION.md diff --git a/product-planning/references/stage-delivery/assets/design-capture/SKILL.md b/product-planning/assets/design-capture/SKILL.md similarity index 100% rename from product-planning/references/stage-delivery/assets/design-capture/SKILL.md rename to product-planning/assets/design-capture/SKILL.md diff --git a/product-planning/references/stage-delivery/assets/design-capture/scripts/build_style_package.py b/product-planning/assets/design-capture/scripts/build_style_package.py similarity index 100% rename from product-planning/references/stage-delivery/assets/design-capture/scripts/build_style_package.py rename to product-planning/assets/design-capture/scripts/build_style_package.py diff --git a/product-planning/references/stage-delivery/assets/design-capture/scripts/capture_design_system.mjs b/product-planning/assets/design-capture/scripts/capture_design_system.mjs similarity index 100% rename from product-planning/references/stage-delivery/assets/design-capture/scripts/capture_design_system.mjs rename to product-planning/assets/design-capture/scripts/capture_design_system.mjs diff --git a/product-planning/references/stage-delivery/assets/design-capture/vendor/brand-capture.js b/product-planning/assets/design-capture/vendor/brand-capture.js similarity index 100% rename from product-planning/references/stage-delivery/assets/design-capture/vendor/brand-capture.js rename to product-planning/assets/design-capture/vendor/brand-capture.js diff --git a/product-planning/references/stage-requirements/assets/diagram-design/SKILL.md b/product-planning/assets/diagram-design/SKILL.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/SKILL.md rename to product-planning/assets/diagram-design/SKILL.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-architecture-dark.html b/product-planning/assets/diagram-design/assets/example-architecture-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-architecture-dark.html rename to product-planning/assets/diagram-design/assets/example-architecture-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-architecture-full.html b/product-planning/assets/diagram-design/assets/example-architecture-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-architecture-full.html rename to product-planning/assets/diagram-design/assets/example-architecture-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-architecture.html b/product-planning/assets/diagram-design/assets/example-architecture.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-architecture.html rename to product-planning/assets/diagram-design/assets/example-architecture.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-bar-dark.html b/product-planning/assets/diagram-design/assets/example-bar-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-bar-dark.html rename to product-planning/assets/diagram-design/assets/example-bar-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-bar-full.html b/product-planning/assets/diagram-design/assets/example-bar-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-bar-full.html rename to product-planning/assets/diagram-design/assets/example-bar-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-bar.html b/product-planning/assets/diagram-design/assets/example-bar.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-bar.html rename to product-planning/assets/diagram-design/assets/example-bar.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-beeswarm-dark.html b/product-planning/assets/diagram-design/assets/example-beeswarm-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-beeswarm-dark.html rename to product-planning/assets/diagram-design/assets/example-beeswarm-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-beeswarm-full.html b/product-planning/assets/diagram-design/assets/example-beeswarm-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-beeswarm-full.html rename to product-planning/assets/diagram-design/assets/example-beeswarm-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-beeswarm.html b/product-planning/assets/diagram-design/assets/example-beeswarm.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-beeswarm.html rename to product-planning/assets/diagram-design/assets/example-beeswarm.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-bubble-dark.html b/product-planning/assets/diagram-design/assets/example-bubble-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-bubble-dark.html rename to product-planning/assets/diagram-design/assets/example-bubble-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-bubble-full.html b/product-planning/assets/diagram-design/assets/example-bubble-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-bubble-full.html rename to product-planning/assets/diagram-design/assets/example-bubble-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-bubble.html b/product-planning/assets/diagram-design/assets/example-bubble.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-bubble.html rename to product-planning/assets/diagram-design/assets/example-bubble.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-bump-dark.html b/product-planning/assets/diagram-design/assets/example-bump-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-bump-dark.html rename to product-planning/assets/diagram-design/assets/example-bump-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-bump-full.html b/product-planning/assets/diagram-design/assets/example-bump-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-bump-full.html rename to product-planning/assets/diagram-design/assets/example-bump-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-bump.html b/product-planning/assets/diagram-design/assets/example-bump.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-bump.html rename to product-planning/assets/diagram-design/assets/example-bump.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-data-flow-dark.html b/product-planning/assets/diagram-design/assets/example-data-flow-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-data-flow-dark.html rename to product-planning/assets/diagram-design/assets/example-data-flow-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-data-flow-full.html b/product-planning/assets/diagram-design/assets/example-data-flow-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-data-flow-full.html rename to product-planning/assets/diagram-design/assets/example-data-flow-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-data-flow.html b/product-planning/assets/diagram-design/assets/example-data-flow.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-data-flow.html rename to product-planning/assets/diagram-design/assets/example-data-flow.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-datalake-dark.html b/product-planning/assets/diagram-design/assets/example-datalake-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-datalake-dark.html rename to product-planning/assets/diagram-design/assets/example-datalake-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-datalake-full.html b/product-planning/assets/diagram-design/assets/example-datalake-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-datalake-full.html rename to product-planning/assets/diagram-design/assets/example-datalake-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-datalake.html b/product-planning/assets/diagram-design/assets/example-datalake.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-datalake.html rename to product-planning/assets/diagram-design/assets/example-datalake.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-db-schema-dark.html b/product-planning/assets/diagram-design/assets/example-db-schema-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-db-schema-dark.html rename to product-planning/assets/diagram-design/assets/example-db-schema-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-db-schema-full.html b/product-planning/assets/diagram-design/assets/example-db-schema-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-db-schema-full.html rename to product-planning/assets/diagram-design/assets/example-db-schema-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-db-schema.html b/product-planning/assets/diagram-design/assets/example-db-schema.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-db-schema.html rename to product-planning/assets/diagram-design/assets/example-db-schema.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-dependency-dark.html b/product-planning/assets/diagram-design/assets/example-dependency-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-dependency-dark.html rename to product-planning/assets/diagram-design/assets/example-dependency-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-dependency-full.html b/product-planning/assets/diagram-design/assets/example-dependency-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-dependency-full.html rename to product-planning/assets/diagram-design/assets/example-dependency-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-dependency.html b/product-planning/assets/diagram-design/assets/example-dependency.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-dependency.html rename to product-planning/assets/diagram-design/assets/example-dependency.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-deployment-dark.html b/product-planning/assets/diagram-design/assets/example-deployment-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-deployment-dark.html rename to product-planning/assets/diagram-design/assets/example-deployment-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-deployment-full.html b/product-planning/assets/diagram-design/assets/example-deployment-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-deployment-full.html rename to product-planning/assets/diagram-design/assets/example-deployment-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-deployment.html b/product-planning/assets/diagram-design/assets/example-deployment.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-deployment.html rename to product-planning/assets/diagram-design/assets/example-deployment.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-dp-integration-dark.html b/product-planning/assets/diagram-design/assets/example-dp-integration-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-dp-integration-dark.html rename to product-planning/assets/diagram-design/assets/example-dp-integration-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-dp-integration-full.html b/product-planning/assets/diagram-design/assets/example-dp-integration-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-dp-integration-full.html rename to product-planning/assets/diagram-design/assets/example-dp-integration-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-dp-integration.html b/product-planning/assets/diagram-design/assets/example-dp-integration.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-dp-integration.html rename to product-planning/assets/diagram-design/assets/example-dp-integration.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-dp-security-matrix-dark.html b/product-planning/assets/diagram-design/assets/example-dp-security-matrix-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-dp-security-matrix-dark.html rename to product-planning/assets/diagram-design/assets/example-dp-security-matrix-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-dp-security-matrix-full.html b/product-planning/assets/diagram-design/assets/example-dp-security-matrix-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-dp-security-matrix-full.html rename to product-planning/assets/diagram-design/assets/example-dp-security-matrix-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-dp-security-matrix.html b/product-planning/assets/diagram-design/assets/example-dp-security-matrix.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-dp-security-matrix.html rename to product-planning/assets/diagram-design/assets/example-dp-security-matrix.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-er-dark.html b/product-planning/assets/diagram-design/assets/example-er-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-er-dark.html rename to product-planning/assets/diagram-design/assets/example-er-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-er-full.html b/product-planning/assets/diagram-design/assets/example-er-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-er-full.html rename to product-planning/assets/diagram-design/assets/example-er-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-er.html b/product-planning/assets/diagram-design/assets/example-er.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-er.html rename to product-planning/assets/diagram-design/assets/example-er.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-fishbone-dark.html b/product-planning/assets/diagram-design/assets/example-fishbone-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-fishbone-dark.html rename to product-planning/assets/diagram-design/assets/example-fishbone-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-fishbone-full.html b/product-planning/assets/diagram-design/assets/example-fishbone-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-fishbone-full.html rename to product-planning/assets/diagram-design/assets/example-fishbone-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-fishbone.html b/product-planning/assets/diagram-design/assets/example-fishbone.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-fishbone.html rename to product-planning/assets/diagram-design/assets/example-fishbone.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-flowchart-dark.html b/product-planning/assets/diagram-design/assets/example-flowchart-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-flowchart-dark.html rename to product-planning/assets/diagram-design/assets/example-flowchart-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-flowchart-full.html b/product-planning/assets/diagram-design/assets/example-flowchart-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-flowchart-full.html rename to product-planning/assets/diagram-design/assets/example-flowchart-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-flowchart.html b/product-planning/assets/diagram-design/assets/example-flowchart.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-flowchart.html rename to product-planning/assets/diagram-design/assets/example-flowchart.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-gantt-dark.html b/product-planning/assets/diagram-design/assets/example-gantt-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-gantt-dark.html rename to product-planning/assets/diagram-design/assets/example-gantt-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-gantt-full.html b/product-planning/assets/diagram-design/assets/example-gantt-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-gantt-full.html rename to product-planning/assets/diagram-design/assets/example-gantt-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-gantt.html b/product-planning/assets/diagram-design/assets/example-gantt.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-gantt.html rename to product-planning/assets/diagram-design/assets/example-gantt.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-heatmap-dark.html b/product-planning/assets/diagram-design/assets/example-heatmap-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-heatmap-dark.html rename to product-planning/assets/diagram-design/assets/example-heatmap-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-heatmap-full.html b/product-planning/assets/diagram-design/assets/example-heatmap-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-heatmap-full.html rename to product-planning/assets/diagram-design/assets/example-heatmap-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-heatmap.html b/product-planning/assets/diagram-design/assets/example-heatmap.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-heatmap.html rename to product-planning/assets/diagram-design/assets/example-heatmap.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-high-level-dark.html b/product-planning/assets/diagram-design/assets/example-high-level-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-high-level-dark.html rename to product-planning/assets/diagram-design/assets/example-high-level-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-high-level-full.html b/product-planning/assets/diagram-design/assets/example-high-level-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-high-level-full.html rename to product-planning/assets/diagram-design/assets/example-high-level-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-high-level-vertical-dark.html b/product-planning/assets/diagram-design/assets/example-high-level-vertical-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-high-level-vertical-dark.html rename to product-planning/assets/diagram-design/assets/example-high-level-vertical-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-high-level-vertical-full.html b/product-planning/assets/diagram-design/assets/example-high-level-vertical-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-high-level-vertical-full.html rename to product-planning/assets/diagram-design/assets/example-high-level-vertical-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-high-level-vertical.html b/product-planning/assets/diagram-design/assets/example-high-level-vertical.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-high-level-vertical.html rename to product-planning/assets/diagram-design/assets/example-high-level-vertical.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-high-level.html b/product-planning/assets/diagram-design/assets/example-high-level.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-high-level.html rename to product-planning/assets/diagram-design/assets/example-high-level.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-import-drawio.html b/product-planning/assets/diagram-design/assets/example-import-drawio.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-import-drawio.html rename to product-planning/assets/diagram-design/assets/example-import-drawio.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-import-excalidraw.html b/product-planning/assets/diagram-design/assets/example-import-excalidraw.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-import-excalidraw.html rename to product-planning/assets/diagram-design/assets/example-import-excalidraw.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-import-mermaid.html b/product-planning/assets/diagram-design/assets/example-import-mermaid.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-import-mermaid.html rename to product-planning/assets/diagram-design/assets/example-import-mermaid.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-it-state-dark.html b/product-planning/assets/diagram-design/assets/example-it-state-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-it-state-dark.html rename to product-planning/assets/diagram-design/assets/example-it-state-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-it-state-full.html b/product-planning/assets/diagram-design/assets/example-it-state-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-it-state-full.html rename to product-planning/assets/diagram-design/assets/example-it-state-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-it-state.html b/product-planning/assets/diagram-design/assets/example-it-state.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-it-state.html rename to product-planning/assets/diagram-design/assets/example-it-state.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-journey-dark.html b/product-planning/assets/diagram-design/assets/example-journey-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-journey-dark.html rename to product-planning/assets/diagram-design/assets/example-journey-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-journey-full.html b/product-planning/assets/diagram-design/assets/example-journey-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-journey-full.html rename to product-planning/assets/diagram-design/assets/example-journey-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-journey.html b/product-planning/assets/diagram-design/assets/example-journey.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-journey.html rename to product-planning/assets/diagram-design/assets/example-journey.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-kanban-dark.html b/product-planning/assets/diagram-design/assets/example-kanban-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-kanban-dark.html rename to product-planning/assets/diagram-design/assets/example-kanban-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-kanban-full.html b/product-planning/assets/diagram-design/assets/example-kanban-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-kanban-full.html rename to product-planning/assets/diagram-design/assets/example-kanban-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-kanban.html b/product-planning/assets/diagram-design/assets/example-kanban.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-kanban.html rename to product-planning/assets/diagram-design/assets/example-kanban.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-layers-dark.html b/product-planning/assets/diagram-design/assets/example-layers-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-layers-dark.html rename to product-planning/assets/diagram-design/assets/example-layers-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-layers-full.html b/product-planning/assets/diagram-design/assets/example-layers-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-layers-full.html rename to product-planning/assets/diagram-design/assets/example-layers-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-layers.html b/product-planning/assets/diagram-design/assets/example-layers.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-layers.html rename to product-planning/assets/diagram-design/assets/example-layers.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-line-dark.html b/product-planning/assets/diagram-design/assets/example-line-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-line-dark.html rename to product-planning/assets/diagram-design/assets/example-line-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-line-full.html b/product-planning/assets/diagram-design/assets/example-line-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-line-full.html rename to product-planning/assets/diagram-design/assets/example-line-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-line.html b/product-planning/assets/diagram-design/assets/example-line.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-line.html rename to product-planning/assets/diagram-design/assets/example-line.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-loop-dark.html b/product-planning/assets/diagram-design/assets/example-loop-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-loop-dark.html rename to product-planning/assets/diagram-design/assets/example-loop-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-loop-full.html b/product-planning/assets/diagram-design/assets/example-loop-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-loop-full.html rename to product-planning/assets/diagram-design/assets/example-loop-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-loop-terminal.html b/product-planning/assets/diagram-design/assets/example-loop-terminal.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-loop-terminal.html rename to product-planning/assets/diagram-design/assets/example-loop-terminal.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-loop.html b/product-planning/assets/diagram-design/assets/example-loop.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-loop.html rename to product-planning/assets/diagram-design/assets/example-loop.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-marimekko-dark.html b/product-planning/assets/diagram-design/assets/example-marimekko-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-marimekko-dark.html rename to product-planning/assets/diagram-design/assets/example-marimekko-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-marimekko-full.html b/product-planning/assets/diagram-design/assets/example-marimekko-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-marimekko-full.html rename to product-planning/assets/diagram-design/assets/example-marimekko-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-marimekko.html b/product-planning/assets/diagram-design/assets/example-marimekko.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-marimekko.html rename to product-planning/assets/diagram-design/assets/example-marimekko.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-medallion-dark.html b/product-planning/assets/diagram-design/assets/example-medallion-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-medallion-dark.html rename to product-planning/assets/diagram-design/assets/example-medallion-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-medallion-full.html b/product-planning/assets/diagram-design/assets/example-medallion-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-medallion-full.html rename to product-planning/assets/diagram-design/assets/example-medallion-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-medallion.html b/product-planning/assets/diagram-design/assets/example-medallion.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-medallion.html rename to product-planning/assets/diagram-design/assets/example-medallion.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-nested-dark.html b/product-planning/assets/diagram-design/assets/example-nested-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-nested-dark.html rename to product-planning/assets/diagram-design/assets/example-nested-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-nested-full.html b/product-planning/assets/diagram-design/assets/example-nested-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-nested-full.html rename to product-planning/assets/diagram-design/assets/example-nested-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-nested.html b/product-planning/assets/diagram-design/assets/example-nested.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-nested.html rename to product-planning/assets/diagram-design/assets/example-nested.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-org-chart-dark.html b/product-planning/assets/diagram-design/assets/example-org-chart-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-org-chart-dark.html rename to product-planning/assets/diagram-design/assets/example-org-chart-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-org-chart-full.html b/product-planning/assets/diagram-design/assets/example-org-chart-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-org-chart-full.html rename to product-planning/assets/diagram-design/assets/example-org-chart-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-org-chart.html b/product-planning/assets/diagram-design/assets/example-org-chart.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-org-chart.html rename to product-planning/assets/diagram-design/assets/example-org-chart.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-paved-road-animated.html b/product-planning/assets/diagram-design/assets/example-paved-road-animated.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-paved-road-animated.html rename to product-planning/assets/diagram-design/assets/example-paved-road-animated.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-polar-dark.html b/product-planning/assets/diagram-design/assets/example-polar-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-polar-dark.html rename to product-planning/assets/diagram-design/assets/example-polar-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-polar-full.html b/product-planning/assets/diagram-design/assets/example-polar-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-polar-full.html rename to product-planning/assets/diagram-design/assets/example-polar-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-polar.html b/product-planning/assets/diagram-design/assets/example-polar.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-polar.html rename to product-planning/assets/diagram-design/assets/example-polar.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-policy-trace-animated.html b/product-planning/assets/diagram-design/assets/example-policy-trace-animated.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-policy-trace-animated.html rename to product-planning/assets/diagram-design/assets/example-policy-trace-animated.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-process-dark.html b/product-planning/assets/diagram-design/assets/example-process-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-process-dark.html rename to product-planning/assets/diagram-design/assets/example-process-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-process-full.html b/product-planning/assets/diagram-design/assets/example-process-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-process-full.html rename to product-planning/assets/diagram-design/assets/example-process-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-process.html b/product-planning/assets/diagram-design/assets/example-process.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-process.html rename to product-planning/assets/diagram-design/assets/example-process.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-pyramid-dark.html b/product-planning/assets/diagram-design/assets/example-pyramid-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-pyramid-dark.html rename to product-planning/assets/diagram-design/assets/example-pyramid-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-pyramid-full.html b/product-planning/assets/diagram-design/assets/example-pyramid-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-pyramid-full.html rename to product-planning/assets/diagram-design/assets/example-pyramid-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-pyramid.html b/product-planning/assets/diagram-design/assets/example-pyramid.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-pyramid.html rename to product-planning/assets/diagram-design/assets/example-pyramid.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-quadrant-consultant.html b/product-planning/assets/diagram-design/assets/example-quadrant-consultant.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-quadrant-consultant.html rename to product-planning/assets/diagram-design/assets/example-quadrant-consultant.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-quadrant-dark.html b/product-planning/assets/diagram-design/assets/example-quadrant-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-quadrant-dark.html rename to product-planning/assets/diagram-design/assets/example-quadrant-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-quadrant-full.html b/product-planning/assets/diagram-design/assets/example-quadrant-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-quadrant-full.html rename to product-planning/assets/diagram-design/assets/example-quadrant-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-quadrant.html b/product-planning/assets/diagram-design/assets/example-quadrant.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-quadrant.html rename to product-planning/assets/diagram-design/assets/example-quadrant.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-queue-animated.html b/product-planning/assets/diagram-design/assets/example-queue-animated.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-queue-animated.html rename to product-planning/assets/diagram-design/assets/example-queue-animated.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-radar-dark.html b/product-planning/assets/diagram-design/assets/example-radar-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-radar-dark.html rename to product-planning/assets/diagram-design/assets/example-radar-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-radar-full.html b/product-planning/assets/diagram-design/assets/example-radar-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-radar-full.html rename to product-planning/assets/diagram-design/assets/example-radar-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-radar.html b/product-planning/assets/diagram-design/assets/example-radar.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-radar.html rename to product-planning/assets/diagram-design/assets/example-radar.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-ridgeline-dark.html b/product-planning/assets/diagram-design/assets/example-ridgeline-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-ridgeline-dark.html rename to product-planning/assets/diagram-design/assets/example-ridgeline-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-ridgeline-full.html b/product-planning/assets/diagram-design/assets/example-ridgeline-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-ridgeline-full.html rename to product-planning/assets/diagram-design/assets/example-ridgeline-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-ridgeline.html b/product-planning/assets/diagram-design/assets/example-ridgeline.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-ridgeline.html rename to product-planning/assets/diagram-design/assets/example-ridgeline.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-sankey-dark.html b/product-planning/assets/diagram-design/assets/example-sankey-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-sankey-dark.html rename to product-planning/assets/diagram-design/assets/example-sankey-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-sankey-full.html b/product-planning/assets/diagram-design/assets/example-sankey-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-sankey-full.html rename to product-planning/assets/diagram-design/assets/example-sankey-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-sankey.html b/product-planning/assets/diagram-design/assets/example-sankey.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-sankey.html rename to product-planning/assets/diagram-design/assets/example-sankey.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-scatter-dark.html b/product-planning/assets/diagram-design/assets/example-scatter-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-scatter-dark.html rename to product-planning/assets/diagram-design/assets/example-scatter-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-scatter-full.html b/product-planning/assets/diagram-design/assets/example-scatter-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-scatter-full.html rename to product-planning/assets/diagram-design/assets/example-scatter-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-scatter.html b/product-planning/assets/diagram-design/assets/example-scatter.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-scatter.html rename to product-planning/assets/diagram-design/assets/example-scatter.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-sequence-dark.html b/product-planning/assets/diagram-design/assets/example-sequence-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-sequence-dark.html rename to product-planning/assets/diagram-design/assets/example-sequence-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-sequence-full.html b/product-planning/assets/diagram-design/assets/example-sequence-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-sequence-full.html rename to product-planning/assets/diagram-design/assets/example-sequence-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-sequence-oauth-dark.html b/product-planning/assets/diagram-design/assets/example-sequence-oauth-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-sequence-oauth-dark.html rename to product-planning/assets/diagram-design/assets/example-sequence-oauth-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-sequence-oauth-full.html b/product-planning/assets/diagram-design/assets/example-sequence-oauth-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-sequence-oauth-full.html rename to product-planning/assets/diagram-design/assets/example-sequence-oauth-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-sequence-oauth.html b/product-planning/assets/diagram-design/assets/example-sequence-oauth.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-sequence-oauth.html rename to product-planning/assets/diagram-design/assets/example-sequence-oauth.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-sequence.html b/product-planning/assets/diagram-design/assets/example-sequence.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-sequence.html rename to product-planning/assets/diagram-design/assets/example-sequence.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-slopegraph-dark.html b/product-planning/assets/diagram-design/assets/example-slopegraph-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-slopegraph-dark.html rename to product-planning/assets/diagram-design/assets/example-slopegraph-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-slopegraph-full.html b/product-planning/assets/diagram-design/assets/example-slopegraph-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-slopegraph-full.html rename to product-planning/assets/diagram-design/assets/example-slopegraph-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-slopegraph.html b/product-planning/assets/diagram-design/assets/example-slopegraph.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-slopegraph.html rename to product-planning/assets/diagram-design/assets/example-slopegraph.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-state-dark.html b/product-planning/assets/diagram-design/assets/example-state-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-state-dark.html rename to product-planning/assets/diagram-design/assets/example-state-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-state-full.html b/product-planning/assets/diagram-design/assets/example-state-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-state-full.html rename to product-planning/assets/diagram-design/assets/example-state-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-state-lifecycle-dark.html b/product-planning/assets/diagram-design/assets/example-state-lifecycle-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-state-lifecycle-dark.html rename to product-planning/assets/diagram-design/assets/example-state-lifecycle-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-state-lifecycle-full.html b/product-planning/assets/diagram-design/assets/example-state-lifecycle-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-state-lifecycle-full.html rename to product-planning/assets/diagram-design/assets/example-state-lifecycle-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-state-lifecycle.html b/product-planning/assets/diagram-design/assets/example-state-lifecycle.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-state-lifecycle.html rename to product-planning/assets/diagram-design/assets/example-state-lifecycle.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-state.html b/product-planning/assets/diagram-design/assets/example-state.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-state.html rename to product-planning/assets/diagram-design/assets/example-state.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-story-map-dark.html b/product-planning/assets/diagram-design/assets/example-story-map-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-story-map-dark.html rename to product-planning/assets/diagram-design/assets/example-story-map-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-story-map-full.html b/product-planning/assets/diagram-design/assets/example-story-map-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-story-map-full.html rename to product-planning/assets/diagram-design/assets/example-story-map-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-story-map.html b/product-planning/assets/diagram-design/assets/example-story-map.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-story-map.html rename to product-planning/assets/diagram-design/assets/example-story-map.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-streamgraph-dark.html b/product-planning/assets/diagram-design/assets/example-streamgraph-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-streamgraph-dark.html rename to product-planning/assets/diagram-design/assets/example-streamgraph-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-streamgraph-full.html b/product-planning/assets/diagram-design/assets/example-streamgraph-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-streamgraph-full.html rename to product-planning/assets/diagram-design/assets/example-streamgraph-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-streamgraph.html b/product-planning/assets/diagram-design/assets/example-streamgraph.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-streamgraph.html rename to product-planning/assets/diagram-design/assets/example-streamgraph.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-swimlane-dark.html b/product-planning/assets/diagram-design/assets/example-swimlane-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-swimlane-dark.html rename to product-planning/assets/diagram-design/assets/example-swimlane-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-swimlane-full.html b/product-planning/assets/diagram-design/assets/example-swimlane-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-swimlane-full.html rename to product-planning/assets/diagram-design/assets/example-swimlane-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-swimlane.html b/product-planning/assets/diagram-design/assets/example-swimlane.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-swimlane.html rename to product-planning/assets/diagram-design/assets/example-swimlane.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-timeline-dark.html b/product-planning/assets/diagram-design/assets/example-timeline-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-timeline-dark.html rename to product-planning/assets/diagram-design/assets/example-timeline-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-timeline-full.html b/product-planning/assets/diagram-design/assets/example-timeline-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-timeline-full.html rename to product-planning/assets/diagram-design/assets/example-timeline-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-timeline.html b/product-planning/assets/diagram-design/assets/example-timeline.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-timeline.html rename to product-planning/assets/diagram-design/assets/example-timeline.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-tree-block-decomposition-dark.html b/product-planning/assets/diagram-design/assets/example-tree-block-decomposition-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-tree-block-decomposition-dark.html rename to product-planning/assets/diagram-design/assets/example-tree-block-decomposition-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-tree-block-decomposition-full.html b/product-planning/assets/diagram-design/assets/example-tree-block-decomposition-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-tree-block-decomposition-full.html rename to product-planning/assets/diagram-design/assets/example-tree-block-decomposition-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-tree-block-decomposition.html b/product-planning/assets/diagram-design/assets/example-tree-block-decomposition.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-tree-block-decomposition.html rename to product-planning/assets/diagram-design/assets/example-tree-block-decomposition.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-tree-dark.html b/product-planning/assets/diagram-design/assets/example-tree-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-tree-dark.html rename to product-planning/assets/diagram-design/assets/example-tree-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-tree-full.html b/product-planning/assets/diagram-design/assets/example-tree-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-tree-full.html rename to product-planning/assets/diagram-design/assets/example-tree-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-tree.html b/product-planning/assets/diagram-design/assets/example-tree.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-tree.html rename to product-planning/assets/diagram-design/assets/example-tree.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-treemap-dark.html b/product-planning/assets/diagram-design/assets/example-treemap-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-treemap-dark.html rename to product-planning/assets/diagram-design/assets/example-treemap-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-treemap-full.html b/product-planning/assets/diagram-design/assets/example-treemap-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-treemap-full.html rename to product-planning/assets/diagram-design/assets/example-treemap-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-treemap.html b/product-planning/assets/diagram-design/assets/example-treemap.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-treemap.html rename to product-planning/assets/diagram-design/assets/example-treemap.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-uml-class-dark.html b/product-planning/assets/diagram-design/assets/example-uml-class-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-uml-class-dark.html rename to product-planning/assets/diagram-design/assets/example-uml-class-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-uml-class-full.html b/product-planning/assets/diagram-design/assets/example-uml-class-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-uml-class-full.html rename to product-planning/assets/diagram-design/assets/example-uml-class-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-uml-class.html b/product-planning/assets/diagram-design/assets/example-uml-class.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-uml-class.html rename to product-planning/assets/diagram-design/assets/example-uml-class.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-venn-dark.html b/product-planning/assets/diagram-design/assets/example-venn-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-venn-dark.html rename to product-planning/assets/diagram-design/assets/example-venn-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-venn-full.html b/product-planning/assets/diagram-design/assets/example-venn-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-venn-full.html rename to product-planning/assets/diagram-design/assets/example-venn-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-venn.html b/product-planning/assets/diagram-design/assets/example-venn.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-venn.html rename to product-planning/assets/diagram-design/assets/example-venn.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-wardley-dark.html b/product-planning/assets/diagram-design/assets/example-wardley-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-wardley-dark.html rename to product-planning/assets/diagram-design/assets/example-wardley-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-wardley-full.html b/product-planning/assets/diagram-design/assets/example-wardley-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-wardley-full.html rename to product-planning/assets/diagram-design/assets/example-wardley-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-wardley.html b/product-planning/assets/diagram-design/assets/example-wardley.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-wardley.html rename to product-planning/assets/diagram-design/assets/example-wardley.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-waterfall-dark.html b/product-planning/assets/diagram-design/assets/example-waterfall-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-waterfall-dark.html rename to product-planning/assets/diagram-design/assets/example-waterfall-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-waterfall-full.html b/product-planning/assets/diagram-design/assets/example-waterfall-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-waterfall-full.html rename to product-planning/assets/diagram-design/assets/example-waterfall-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/example-waterfall.html b/product-planning/assets/diagram-design/assets/example-waterfall.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/example-waterfall.html rename to product-planning/assets/diagram-design/assets/example-waterfall.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/icons.html b/product-planning/assets/diagram-design/assets/icons.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/icons.html rename to product-planning/assets/diagram-design/assets/icons.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/index.html b/product-planning/assets/diagram-design/assets/index.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/index.html rename to product-planning/assets/diagram-design/assets/index.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/template-dark.html b/product-planning/assets/diagram-design/assets/template-dark.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/template-dark.html rename to product-planning/assets/diagram-design/assets/template-dark.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/template-full.html b/product-planning/assets/diagram-design/assets/template-full.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/template-full.html rename to product-planning/assets/diagram-design/assets/template-full.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/template-motion.html b/product-planning/assets/diagram-design/assets/template-motion.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/template-motion.html rename to product-planning/assets/diagram-design/assets/template-motion.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/template-terminal.html b/product-planning/assets/diagram-design/assets/template-terminal.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/template-terminal.html rename to product-planning/assets/diagram-design/assets/template-terminal.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/assets/template.html b/product-planning/assets/diagram-design/assets/template.html similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/assets/template.html rename to product-planning/assets/diagram-design/assets/template.html diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/animation.md b/product-planning/assets/diagram-design/references/animation.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/animation.md rename to product-planning/assets/diagram-design/references/animation.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/doctor.md b/product-planning/assets/diagram-design/references/doctor.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/doctor.md rename to product-planning/assets/diagram-design/references/doctor.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/export-registry.md b/product-planning/assets/diagram-design/references/export-registry.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/export-registry.md rename to product-planning/assets/diagram-design/references/export-registry.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/export.md b/product-planning/assets/diagram-design/references/export.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/export.md rename to product-planning/assets/diagram-design/references/export.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/import-drawio.md b/product-planning/assets/diagram-design/references/import-drawio.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/import-drawio.md rename to product-planning/assets/diagram-design/references/import-drawio.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/import-excalidraw.md b/product-planning/assets/diagram-design/references/import-excalidraw.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/import-excalidraw.md rename to product-planning/assets/diagram-design/references/import-excalidraw.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/import-mermaid.md b/product-planning/assets/diagram-design/references/import-mermaid.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/import-mermaid.md rename to product-planning/assets/diagram-design/references/import-mermaid.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/onboarding.md b/product-planning/assets/diagram-design/references/onboarding.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/onboarding.md rename to product-planning/assets/diagram-design/references/onboarding.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/output-spec.md b/product-planning/assets/diagram-design/references/output-spec.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/output-spec.md rename to product-planning/assets/diagram-design/references/output-spec.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/primitive-annotation.md b/product-planning/assets/diagram-design/references/primitive-annotation.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/primitive-annotation.md rename to product-planning/assets/diagram-design/references/primitive-annotation.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/primitive-icons.md b/product-planning/assets/diagram-design/references/primitive-icons.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/primitive-icons.md rename to product-planning/assets/diagram-design/references/primitive-icons.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/primitive-sketchy.md b/product-planning/assets/diagram-design/references/primitive-sketchy.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/primitive-sketchy.md rename to product-planning/assets/diagram-design/references/primitive-sketchy.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/primitive-terminal.md b/product-planning/assets/diagram-design/references/primitive-terminal.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/primitive-terminal.md rename to product-planning/assets/diagram-design/references/primitive-terminal.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/profiles.md b/product-planning/assets/diagram-design/references/profiles.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/profiles.md rename to product-planning/assets/diagram-design/references/profiles.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/semantic-patterns.md b/product-planning/assets/diagram-design/references/semantic-patterns.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/semantic-patterns.md rename to product-planning/assets/diagram-design/references/semantic-patterns.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/style-guide.md b/product-planning/assets/diagram-design/references/style-guide.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/style-guide.md rename to product-planning/assets/diagram-design/references/style-guide.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-architecture.md b/product-planning/assets/diagram-design/references/type-architecture.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-architecture.md rename to product-planning/assets/diagram-design/references/type-architecture.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-bar.md b/product-planning/assets/diagram-design/references/type-bar.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-bar.md rename to product-planning/assets/diagram-design/references/type-bar.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-data-flow.md b/product-planning/assets/diagram-design/references/type-data-flow.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-data-flow.md rename to product-planning/assets/diagram-design/references/type-data-flow.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-db-schema.md b/product-planning/assets/diagram-design/references/type-db-schema.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-db-schema.md rename to product-planning/assets/diagram-design/references/type-db-schema.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-dependency.md b/product-planning/assets/diagram-design/references/type-dependency.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-dependency.md rename to product-planning/assets/diagram-design/references/type-dependency.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-deployment.md b/product-planning/assets/diagram-design/references/type-deployment.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-deployment.md rename to product-planning/assets/diagram-design/references/type-deployment.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-dp-integration.md b/product-planning/assets/diagram-design/references/type-dp-integration.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-dp-integration.md rename to product-planning/assets/diagram-design/references/type-dp-integration.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-dp-security-matrix.md b/product-planning/assets/diagram-design/references/type-dp-security-matrix.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-dp-security-matrix.md rename to product-planning/assets/diagram-design/references/type-dp-security-matrix.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-er.md b/product-planning/assets/diagram-design/references/type-er.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-er.md rename to product-planning/assets/diagram-design/references/type-er.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-fishbone.md b/product-planning/assets/diagram-design/references/type-fishbone.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-fishbone.md rename to product-planning/assets/diagram-design/references/type-fishbone.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-flowchart.md b/product-planning/assets/diagram-design/references/type-flowchart.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-flowchart.md rename to product-planning/assets/diagram-design/references/type-flowchart.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-gantt.md b/product-planning/assets/diagram-design/references/type-gantt.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-gantt.md rename to product-planning/assets/diagram-design/references/type-gantt.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-heatmap.md b/product-planning/assets/diagram-design/references/type-heatmap.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-heatmap.md rename to product-planning/assets/diagram-design/references/type-heatmap.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-high-level.md b/product-planning/assets/diagram-design/references/type-high-level.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-high-level.md rename to product-planning/assets/diagram-design/references/type-high-level.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-it-state.md b/product-planning/assets/diagram-design/references/type-it-state.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-it-state.md rename to product-planning/assets/diagram-design/references/type-it-state.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-journey.md b/product-planning/assets/diagram-design/references/type-journey.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-journey.md rename to product-planning/assets/diagram-design/references/type-journey.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-kanban.md b/product-planning/assets/diagram-design/references/type-kanban.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-kanban.md rename to product-planning/assets/diagram-design/references/type-kanban.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-layers.md b/product-planning/assets/diagram-design/references/type-layers.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-layers.md rename to product-planning/assets/diagram-design/references/type-layers.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-line.md b/product-planning/assets/diagram-design/references/type-line.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-line.md rename to product-planning/assets/diagram-design/references/type-line.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-loop.md b/product-planning/assets/diagram-design/references/type-loop.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-loop.md rename to product-planning/assets/diagram-design/references/type-loop.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-medallion.md b/product-planning/assets/diagram-design/references/type-medallion.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-medallion.md rename to product-planning/assets/diagram-design/references/type-medallion.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-nested.md b/product-planning/assets/diagram-design/references/type-nested.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-nested.md rename to product-planning/assets/diagram-design/references/type-nested.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-org-chart.md b/product-planning/assets/diagram-design/references/type-org-chart.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-org-chart.md rename to product-planning/assets/diagram-design/references/type-org-chart.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-polar.md b/product-planning/assets/diagram-design/references/type-polar.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-polar.md rename to product-planning/assets/diagram-design/references/type-polar.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-process.md b/product-planning/assets/diagram-design/references/type-process.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-process.md rename to product-planning/assets/diagram-design/references/type-process.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-pyramid.md b/product-planning/assets/diagram-design/references/type-pyramid.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-pyramid.md rename to product-planning/assets/diagram-design/references/type-pyramid.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-quadrant.md b/product-planning/assets/diagram-design/references/type-quadrant.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-quadrant.md rename to product-planning/assets/diagram-design/references/type-quadrant.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-radar.md b/product-planning/assets/diagram-design/references/type-radar.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-radar.md rename to product-planning/assets/diagram-design/references/type-radar.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-sankey.md b/product-planning/assets/diagram-design/references/type-sankey.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-sankey.md rename to product-planning/assets/diagram-design/references/type-sankey.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-scatter.md b/product-planning/assets/diagram-design/references/type-scatter.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-scatter.md rename to product-planning/assets/diagram-design/references/type-scatter.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-sequence.md b/product-planning/assets/diagram-design/references/type-sequence.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-sequence.md rename to product-planning/assets/diagram-design/references/type-sequence.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-state.md b/product-planning/assets/diagram-design/references/type-state.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-state.md rename to product-planning/assets/diagram-design/references/type-state.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-story-map.md b/product-planning/assets/diagram-design/references/type-story-map.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-story-map.md rename to product-planning/assets/diagram-design/references/type-story-map.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-swimlane.md b/product-planning/assets/diagram-design/references/type-swimlane.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-swimlane.md rename to product-planning/assets/diagram-design/references/type-swimlane.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-timeline.md b/product-planning/assets/diagram-design/references/type-timeline.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-timeline.md rename to product-planning/assets/diagram-design/references/type-timeline.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-tree.md b/product-planning/assets/diagram-design/references/type-tree.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-tree.md rename to product-planning/assets/diagram-design/references/type-tree.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-treemap.md b/product-planning/assets/diagram-design/references/type-treemap.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-treemap.md rename to product-planning/assets/diagram-design/references/type-treemap.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-uml-class.md b/product-planning/assets/diagram-design/references/type-uml-class.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-uml-class.md rename to product-planning/assets/diagram-design/references/type-uml-class.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-venn.md b/product-planning/assets/diagram-design/references/type-venn.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-venn.md rename to product-planning/assets/diagram-design/references/type-venn.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-wardley.md b/product-planning/assets/diagram-design/references/type-wardley.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-wardley.md rename to product-planning/assets/diagram-design/references/type-wardley.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/references/type-waterfall.md b/product-planning/assets/diagram-design/references/type-waterfall.md similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/references/type-waterfall.md rename to product-planning/assets/diagram-design/references/type-waterfall.md diff --git a/product-planning/references/stage-requirements/assets/diagram-design/scripts/drawio_extract.py b/product-planning/assets/diagram-design/scripts/drawio_extract.py similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/scripts/drawio_extract.py rename to product-planning/assets/diagram-design/scripts/drawio_extract.py diff --git a/product-planning/references/stage-requirements/assets/diagram-design/scripts/excalidraw_extract.py b/product-planning/assets/diagram-design/scripts/excalidraw_extract.py similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/scripts/excalidraw_extract.py rename to product-planning/assets/diagram-design/scripts/excalidraw_extract.py diff --git a/product-planning/references/stage-requirements/assets/diagram-design/scripts/mermaid_extract.py b/product-planning/assets/diagram-design/scripts/mermaid_extract.py similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/scripts/mermaid_extract.py rename to product-planning/assets/diagram-design/scripts/mermaid_extract.py diff --git a/product-planning/references/stage-requirements/assets/diagram-design/scripts/self_check.py b/product-planning/assets/diagram-design/scripts/self_check.py similarity index 100% rename from product-planning/references/stage-requirements/assets/diagram-design/scripts/self_check.py rename to product-planning/assets/diagram-design/scripts/self_check.py diff --git a/product-planning/assets/element-picker/SKILL.md b/product-planning/assets/element-picker/SKILL.md new file mode 100644 index 0000000..e834681 --- /dev/null +++ b/product-planning/assets/element-picker/SKILL.md @@ -0,0 +1,77 @@ +--- +name: element-picker +description: ③段独立工具 —— 在浏览器里点选任意组件，取出它的 CSS 选择器与所属网页，复制给 AI 后可直接定位到源码改样式/改结构。两条路：① Chrome 扩展（装一次，任意网页可用，按 Z 或点胶囊进拾取模式）；② 页面注入（本地开发页加一行 script ＋ URL 带 ?pick）。点「确认」后剪贴板得到「选择器：… / 网页：…」两行，同时把完整上下文（文本 / class / 属性 / 尺寸 / 关键计算样式 / HTML 片段）落到 marks/_ui-marks.json。当用户说「选中这个组件」「把这个元素的位置给你」「改这个页面的样式」「这个按钮在哪」「点选元素」「取组件路径」「改界面」「调样式」时调用。 +version: "1.0" +updated_at: "2026-10-16" +agent_created: true +--- + +# element-picker · 页面元素拾取（③段独立工具） + +把「页面上那个组件」变成「AI 能精确定位的坐标」—— 点一下，拿到它的选择器与所属网页，交给 AI 改代码。 + +## 一、什么时候用 + +- 用户说「选中这个组件」「把这个元素的位置给你」「改这个页面的样式」「这个按钮在哪」。 +- 用户要改界面，但靠嘴说不清是哪一个（"左上角那个"、"第二张卡片"，讲不准）。 +- 做完原型/页面后做局部微调，需要把改动点精确指出来。 + +## 二、两条路，按场景二选一 + +### 路 1 · Chrome 扩展（任意网页都能用） + +装一次，之后每个页面都有拾取器。适合改线上页面、别人的网站、或不在本地开发的服务。 + +装法：`chrome://extensions/` → 开发者模式 → 「加载已解压的扩展程序」→ 选本目录下的 `chrome-extension/`。 +扩展目录变了（换机器、换路径）要重新加载一次。 + +用法：打开任意页面 → 右下角有半透明胶囊（拾取器已在）→ 按 `Z`、点胶囊、点扩展图标、或按 `Alt+Shift+Z` 进拾取模式 → 点元素 → 确认窗里点「确认」。 + +### 路 2 · 页面注入（本地开发页） + +只给本地开发中的页面用。在页面 HTML 的 `` 前加一行，访问时 URL 带 `?pick`： + +```html + +``` + +不带 `?pick` 时脚本完全不碰页面，所以可以常留在开发页里。 + +## 三、点一下之后拿到什么 + +- 剪贴板两行，直接粘给 AI 即可： + +``` +选择器：div#recentScriptsList > button.recent-card:nth-of-type(3) +网页：短视频工作台 +``` + +- 同时往 `marks/_ui-marks.json` 追加一条完整上下文：选择器、祖先路径、元素文本、class 列表、`data-*` 属性、位置尺寸、关键计算样式、`outerHTML` 片段。选择器定位"在哪儿"，这份档案定位"是哪一个"。 + +## 四、服务怎么起 + +扩展与注入脚本都要连本地服务（可选 —— 不连也能复制，只是少一份存档）： + +```bash +node ui-picker-server.js 8890 +``` + +端点：`GET /picker.js`、`POST /mark`、`GET /marks`、`POST /clear`、`GET /health`。零依赖，只用 Node 标准库。 + +## 五、选择器的准确边界 + +- 选择器描述的是元素在 DOM 里的**位置**（标签 ＋ class ＋ 第几个），不是它的**身份**。生成时会自校验「是否恰好只命中这一个」，不通过就退到每一级都带 `:nth-of-type` 的完整树路径。 +- 动态列表增删或换序之后，同一条选择器可能落到别的条目上 —— 所以它是"此刻的点位"，不是长期坐标。 +- 真正落到源码的路径是：从选择器里读 class 名 → 去项目源码里反查是哪段模板渲染的 → 用存档里的文本/属性/HTML 片段交叉确认。 + +## 六、铁律 + +1、**默认不激活**。拾取模式会接管页面点击，所以扩展在每个页面只挂一个半透明胶囊，等用户按 `Z` 或点它才进拾取模式；退出后页面点击立刻恢复正常。 +2、**只落本地**。不上传任何数据，不调外部接口；存档只写在技能目录下的 `marks/` 里。 +3、**页内按键**：`Z` 进/出拾取模式，`Esc` 有弹窗先关弹窗、没弹窗就退出拾取模式，`Ctrl+Enter` 等同确认窗的「确认」。 +4、**浏览器内部页面注入不了**（`chrome://`、扩展商店、其它浏览器内部页），这些页面按 `Z` 不会有反应，属正常。 + +## 七、改代码怎么生效 + +- 注入版：改完脚本刷新页面即可（响应头带 `no-store`，不吃缓存）。 +- 扩展版：改完在 `chrome://extensions/` 点本扩展卡片的刷新（⟳），再刷新目标页面。不需要重新「加载已解压的扩展程序」。 diff --git a/product-planning/assets/element-picker/chrome-extension/README.md b/product-planning/assets/element-picker/chrome-extension/README.md new file mode 100644 index 0000000..fefe441 --- /dev/null +++ b/product-planning/assets/element-picker/chrome-extension/README.md @@ -0,0 +1,65 @@ +# 元素路径拾取器 · Chrome 扩展 + +在每个网页上点选元素，把它的 CSS 选择器和页面地址复制到剪贴板 —— 粘进 AI 对话框里就能精确改样式。 + +拾取器会**自动注入到所有页面**（默认不激活，页面右下角有一个半透明小胶囊），所以打开新页面就能直接用，不用先点扩展图标。 + +## 安装 + +1、在 Chrome 地址栏输入 `chrome://extensions/` 回车。 + +2、打开右上角的「开发者模式」开关。 + +3、点左上角「加载已解压的扩展程序」，选中本目录（`chrome-extension`），确定。 + +装完工具栏上会出现一个扩展图标（灰块，因为没配图标）。要固定到工具栏：点浏览器右上角的拼图图标 → 在本扩展右侧点图钉。 + +## 用法 + +1、打开任意网页，页面右下角会有一个半透明的小胶囊（鼠标移上去变清晰）—— 这就是拾取器，已经在了。 + +2、按 `Z` 键，或点那个胶囊上的「开启」，或点扩展图标，或按 `Alt+Shift+Z` —— 任选一种进入拾取模式，胶囊上的圆点变绿、文字变「拾取中」。 + +3、鼠标划过元素出现蓝框、框上方显示路径；点一下要改的元素，弹出确认窗。 + +4、确认窗里有三行信息：元素标签、选择器、网页（下面还有一行元素文本，只给你核对点对没有，不进剪贴板）。 + +5、点「确认」—— 剪贴板里就是两行： + +``` +选择器：main#view > section.detail-card > button.primary:nth-of-type(2) +网页：短视频工作台 +``` + +粘进对话框，再补一句要改成什么即可。想连着点几处就一直点，「确认」之后窗自己关，拾取模式仍然开着。 + +## 关闭 + +- 按 `Esc`：有弹窗先关弹窗，没弹窗就退出拾取模式。 +- 也可以再按一次 `Z`，或点胶囊上的「关闭」，或再点一次扩展图标。 + +## 改快捷键 + +`chrome://extensions/shortcuts` 里找到本扩展，给「进/出元素拾取模式」换一个顺手的组合键。 + +## 可选：本地存档服务 + +每次点「确认」时，扩展会顺带把一条完整上下文（选择器、祖先路径、class、属性、尺寸、关键计算样式、HTML 片段）POST 到 `http://127.0.0.1:8890/mark`，落到本工具目录下的 `marks/_ui-marks.json`。 + +这个服务是上一层目录里的 `ui-picker-server.js`，起法（在本目录下执行）： + +``` +node ../ui-picker-server.js 8890 +``` + +没起也不影响使用 —— 复制功能完全独立，只是少一份存档。 + +## 已知边界 + +- `chrome://` 开头、Chrome 应用商店、以及其它浏览器内部页面不允许扩展注入，在这些页面上按 `Z` 不会有反应。 +- 因为要注入到每个页面，安装/更新后 Chrome 会提示本扩展可以「读取和更改您在所有网站上的数据」—— 它只在本地读写一个 shadow DOM 浮层与剪贴板，不上传任何内容。 +- 复制走系统剪贴板接口，失败时自动退到备用方式；若两条都失败，弹窗里会直接把内容显示出来，手动选中复制即可。 + +## 改了代码怎么生效 + +改完本目录里的文件后：在 `chrome://extensions/` 点本扩展卡片上的刷新（⟳）按钮，再刷新页面。不需要重新「加载已解压的扩展程序」。 diff --git a/product-planning/assets/element-picker/chrome-extension/background.js b/product-planning/assets/element-picker/chrome-extension/background.js new file mode 100644 index 0000000..29f364c --- /dev/null +++ b/product-planning/assets/element-picker/chrome-extension/background.js @@ -0,0 +1,25 @@ +/** + * background.js —— 工具栏图标与快捷键的入口 + * + * 拾取器已由 manifest 的 content_scripts 自动注入到每个页面（默认不激活）， + * 所以点图标或按 Alt+Shift+Z 只需要给页面里那份发一条「切换」消息。 + * 若该页面没有拾取器（刚装上扩展时已开着的旧标签、或内部页面），再补注入一份。 + */ +function toggle(tab) { + if (!tab || !tab.id) return; + + chrome.tabs.sendMessage(tab.id, { type: 'ui-picker-toggle' }, () => { + if (chrome.runtime.lastError) { + // 页面里还没有拾取器 → 补注入（chrome:// 等内部页面注入会失败，忽略） + chrome.scripting + .executeScript({ target: { tabId: tab.id }, files: ['picker.js'] }) + .catch(() => {}); + } + }); +} + +chrome.action.onClicked.addListener(toggle); + +chrome.commands.onCommand.addListener((command, tab) => { + if (command === 'toggle-picker') toggle(tab); +}); diff --git a/product-planning/assets/element-picker/chrome-extension/manifest.json b/product-planning/assets/element-picker/chrome-extension/manifest.json new file mode 100644 index 0000000..64e397d --- /dev/null +++ b/product-planning/assets/element-picker/chrome-extension/manifest.json @@ -0,0 +1,30 @@ +{ + "manifest_version": 3, + "name": "元素路径拾取器", + "version": "1.1.0", + "description": "点选任意页面元素，把它的 CSS 选择器和页面地址复制到剪贴板 —— 粘进 AI 对话框就能精确改样式。", + "permissions": ["activeTab", "scripting", "clipboardWrite", "storage"], + "host_permissions": ["http://127.0.0.1:8890/*"], + "background": { + "service_worker": "background.js" + }, + "content_scripts": [ + { + "matches": [""], + "js": ["picker.js"], + "run_at": "document_idle", + "all_frames": false + } + ], + "action": { + "default_title": "进/出元素拾取模式（Alt+Shift+Z）" + }, + "commands": { + "toggle-picker": { + "suggested_key": { + "default": "Alt+Shift+Z" + }, + "description": "进/出元素拾取模式" + } + } +} diff --git a/product-planning/assets/element-picker/chrome-extension/picker.js b/product-planning/assets/element-picker/chrome-extension/picker.js new file mode 100644 index 0000000..058b452 --- /dev/null +++ b/product-planning/assets/element-picker/chrome-extension/picker.js @@ -0,0 +1,374 @@ +/** + * picker.js —— 元素路径拾取器（Chrome 扩展版 · v3 确认式弹窗） + * + * 触发：点扩展图标 或 按 Alt+Shift+Z → 注入本脚本并进入拾取模式。 + * 已注入的页面再触发一次 = 进/出拾取模式（单例切换，不会叠加多层 UI）。 + * 操作：鼠标划过元素出蓝框 → 点一下 → 弹窗给出该组件的「选择器 / 地址 / 文本」， + * 点「确认」复制进剪贴板，粘到对话框里说明怎么改即可。 + * + * 在扩展的 isolated world 里跑，不受页面 CSP 限制，也不会和页面自己的脚本打架。 + */ +(function () { + 'use strict'; + + // 已经注入过 → 只做模式切换 + if (window.__uiPickerToggle) { + window.__uiPickerToggle(); + return; + } + + var API = 'http://127.0.0.1:8890'; // 本地拾取服务（可选存档；没起就静默跳过） + + /* ---------- 路径与上下文提取 ---------- */ + + /* 生成候选路径；forceNth = true 时每一级都带 :nth-of-type，等于完整树路径 */ + function rawPath(el, forceNth) { + if (!el || el.nodeType !== 1) return ''; + if (el.id && document.querySelectorAll('#' + CSS.escape(el.id)).length === 1) { + return '#' + CSS.escape(el.id); + } + var parts = []; + var node = el; + while (node && node.nodeType === 1 && node !== document.documentElement) { + var sel = node.nodeName.toLowerCase(); + if (node.id) { + sel += '#' + CSS.escape(node.id); + parts.unshift(sel); + break; + } + var cls = Array.prototype.slice.call(node.classList).filter(function (c) { + return !/^(ng-|css-|sc-|is-|has-)/.test(c); + }).slice(0, 3); + if (cls.length) sel += '.' + cls.map(function (c) { return CSS.escape(c); }).join('.'); + var parent = node.parentElement; + if (parent) { + var same = Array.prototype.filter.call(parent.children, function (c) { + return c.nodeName === node.nodeName; + }); + if (forceNth || same.length > 1) sel += ':nth-of-type(' + (same.indexOf(node) + 1) + ')'; + } + parts.unshift(sel); + node = parent; + if (parts.length >= 7) break; + } + return parts.join(' > '); + } + + /* 校验：这条选择器在页面上是不是恰好只命中这一个元素 */ + function matchesExactly(sel, el) { + if (!sel) return false; + try { + var list = document.querySelectorAll(sel); + return list.length === 1 && list[0] === el; + } catch (e) { + return false; + } + } + + /* 先给最短路径；若不唯一，退到每一级都带下标的完整路径 */ + function cssPath(el) { + var base = rawPath(el, false); + if (matchesExactly(base, el)) return base; + var full = rawPath(el, true); + if (matchesExactly(full, el)) return full; + return base; + } + + function breadcrumb(el) { + var names = []; + var node = el; + while (node && node.nodeType === 1 && node !== document.body) { + var n = node.nodeName.toLowerCase(); + if (node.id) n += '#' + node.id; + else if (node.classList.length) n += '.' + Array.prototype.slice.call(node.classList, 0, 2).join('.'); + names.unshift(n); + node = node.parentElement; + } + return names.join(' > '); + } + + var STYLE_KEYS = ['display', 'position', 'width', 'height', 'margin', 'padding', + 'fontSize', 'fontWeight', 'lineHeight', 'color', 'backgroundColor', 'border', 'borderRadius', + 'boxShadow', 'gap', 'flexDirection', 'justifyContent', 'alignItems', 'gridTemplateColumns', 'textAlign']; + + function stylesOf(el) { + var cs = getComputedStyle(el); + var out = {}; + STYLE_KEYS.forEach(function (k) { out[k] = cs[k]; }); + return out; + } + + function attrsOf(el) { + var out = {}; + Array.prototype.forEach.call(el.attributes, function (a) { + if (a.name === 'style' || a.name === 'class' || a.name === 'id') return; + var v = a.value || ''; + out[a.name] = v.length > 120 ? v.slice(0, 120) + '…' : v; + }); + return out; + } + + function textOf(el) { + return (el.textContent || '').trim().replace(/\s+/g, ' '); + } + + function collect(el, sel) { + var r = el.getBoundingClientRect(); + return { + page: location.href, + pageTitle: (document.title || '').trim(), + note: '', + selector: sel, + breadcrumb: breadcrumb(el), + tag: el.tagName.toLowerCase(), + classes: Array.prototype.slice.call(el.classList), + text: textOf(el).slice(0, 200), + attrs: attrsOf(el), + rect: { x: Math.round(r.x), y: Math.round(r.y), w: Math.round(r.width), h: Math.round(r.height) }, + styles: stylesOf(el), + html: el.outerHTML.length > 1500 ? el.outerHTML.slice(0, 1500) + ' ' : el.outerHTML + }; + } + + /* ---------- 剪贴板 ---------- */ + + function legacyCopy(text) { + try { + var ta = document.createElement('textarea'); + ta.value = text; + ta.setAttribute('readonly', ''); + ta.style.cssText = 'position:fixed;top:-1000px;left:-1000px;opacity:0;'; + document.body.appendChild(ta); + ta.select(); + ta.setSelectionRange(0, ta.value.length); + var ok = document.execCommand('copy'); + ta.remove(); + return ok; + } catch (e) { + return false; + } + } + + function copyText(text) { + try { + if (navigator.clipboard && navigator.clipboard.writeText) { + navigator.clipboard.writeText(text).then(function () {}, function () { legacyCopy(text); }); + return true; + } + } catch (e) {} + return legacyCopy(text); + } + + /* ---------- UI ---------- */ + + var host = document.createElement('div'); + host.id = '__ui_picker_host'; + host.style.cssText = 'position:fixed;inset:0;pointer-events:none;z-index:2147483647;'; + document.documentElement.appendChild(host); + var root = host.attachShadow({ mode: 'open' }); + + root.innerHTML = [ + '', + '', + '', + '
未开启', + '已复制 0', + '
', + '
' + ].join(''); + + var box = root.querySelector('.box'); + var tag = root.querySelector('.tag'); + var dot = root.querySelector('.dot'); + var stEl = root.querySelector('.st'); + var cntEl = root.querySelector('.cnt'); + var btnToggle = root.querySelector('.toggle'); + var toast = root.querySelector('.toast'); + var copied = 0; + var active = false; + var hovered = null; + var dialog = null; + + function toastMsg(msg, ms) { + toast.textContent = msg; + toast.classList.add('show'); + clearTimeout(toast.__t); + toast.__t = setTimeout(function () { toast.classList.remove('show'); }, ms || 2600); + } + + function drawBox(el, hit) { + if (!el) { box.hidden = true; tag.hidden = true; return; } + var r = el.getBoundingClientRect(); + box.style.left = r.left + 'px'; + box.style.top = r.top + 'px'; + box.style.width = r.width + 'px'; + box.style.height = r.height + 'px'; + box.classList.toggle('hit', !!hit); + box.hidden = false; + tag.textContent = cssPath(el); + tag.style.left = r.left + 'px'; + tag.style.top = Math.max(0, r.top - 20) + 'px'; + tag.hidden = false; + } + + function isOurs(e) { + return e.composedPath && e.composedPath().indexOf(host) !== -1; + } + + function closeDialog() { + if (dialog) { dialog.remove(); dialog = null; } + } + + function openDialog(el) { + closeDialog(); + + var sel = cssPath(el); + var pageName = (document.title || '').trim() || location.hostname; + var txt = textOf(el).slice(0, 80); + + var d = document.createElement('div'); + d.className = 'dlg'; + d.innerHTML = + '
' + + '
' + + '
' + + (txt ? '
' : '') + + '
'; + + d.querySelector('.hd').textContent = el.tagName.toLowerCase() + + (el.classList.length ? '.' + el.classList[0] : ''); + d.querySelector('.sel').textContent = sel; + d.querySelector('.url').textContent = pageName; + if (txt) d.querySelector('.txt').textContent = txt; + + root.appendChild(d); + dialog = d; + d.tabIndex = -1; + try { d.focus({ preventScroll: true }); } catch (e) {} + + var r = el.getBoundingClientRect(); + d.style.left = Math.min(Math.max(8, r.left), Math.max(8, innerWidth - 446)) + 'px'; + d.style.top = (r.bottom + 12 + d.offsetHeight > innerHeight) + ? Math.max(8, r.top - d.offsetHeight - 12) + 'px' + : r.bottom + 12 + 'px'; + + d.querySelector('.cancel').addEventListener('click', closeDialog); + d.querySelector('.ok').addEventListener('click', function () { + var payload = '选择器：' + sel + '\n网页：' + pageName; + var ok = copyText(payload); + copied += 1; + cntEl.textContent = copied; + drawBox(el, true); + toastMsg((ok ? '已复制：\n' : '剪贴板被拒，内容如下：\n') + payload); + closeDialog(); + try { + fetch(API + '/mark', { + method: 'POST', + headers: { 'Content-Type': 'application/json' }, + body: JSON.stringify(collect(el, sel)) + }).catch(function () {}); + } catch (err) {} + }); + + d.addEventListener('keydown', function (e) { + if (e.key === 'Escape') closeDialog(); + if (e.key === 'Enter' && (e.ctrlKey || e.metaKey)) d.querySelector('.ok').click(); + }); + } + + function onMove(e) { + if (!active || dialog || isOurs(e)) return; + hovered = e.target; + drawBox(hovered, false); + } + + function onDown(e) { + if (!active || isOurs(e)) return; + e.preventDefault(); + e.stopPropagation(); + } + + function onClick(e) { + if (!active || isOurs(e)) return; + e.preventDefault(); + e.stopPropagation(); + openDialog(e.target); + } + + function setActive(v) { + active = v; + dot.classList.toggle('on', v); + stEl.textContent = v ? '拾取中' : '未开启'; + btnToggle.textContent = v ? '关闭' : '开启'; + document.documentElement.style.cursor = v ? 'crosshair' : ''; + if (!v) { drawBox(null); hovered = null; closeDialog(); } + } + + btnToggle.addEventListener('click', function () { setActive(!active); }); + + document.addEventListener('mousemove', onMove, true); + document.addEventListener('mousedown', onDown, true); + document.addEventListener('click', onClick, true); + window.addEventListener('keydown', function (e) { + // Esc 优先：有弹窗就关弹窗，没弹窗就退出拾取模式 —— 焦点在哪儿都生效 + if (e.key === 'Escape') { + if (dialog) closeDialog(); + else if (active) setActive(false); + e.preventDefault(); + return; + } + if (isOurs(e)) return; + var t = e.target; + if (t && (t.tagName === 'INPUT' || t.tagName === 'TEXTAREA' || t.isContentEditable)) return; + if (e.key === 'z' || e.key === 'Z') { e.preventDefault(); setActive(!active); } + }, true); + window.addEventListener('scroll', function () { if (hovered) drawBox(hovered); }, true); + + // 点图标 / 快捷键 / 页面内按键都走这里切换模式，不重建 UI + window.__uiPickerToggle = function () { setActive(!active); }; + + // 接收 background 的切换消息（点图标、按 Alt+Shift+Z、点工具栏图标） + try { + if (typeof chrome !== 'undefined' && chrome.runtime && chrome.runtime.onMessage) { + chrome.runtime.onMessage.addListener(function (msg) { + if (msg && msg.type === 'ui-picker-toggle') setActive(!active); + }); + } + } catch (e) {} + + // 自动注入到每个页面，但默认不激活，免得抢走正常点击 + setActive(false); +})(); diff --git a/product-planning/assets/element-picker/picker.js b/product-planning/assets/element-picker/picker.js new file mode 100644 index 0000000..1f67b1d --- /dev/null +++ b/product-planning/assets/element-picker/picker.js @@ -0,0 +1,360 @@ +/** + * picker.js —— 页面元素拾取器 v3（确认式弹窗） + * + * 配合 tools/ui-picker/ui-picker-server.js 使用： + * 页面引入 + * URL 带 ?pick 才激活（不带就完全不碰页面）。 + * + * 操作：鼠标划过元素出蓝框 → 点一下 → 弹窗里直接给出该组件的 + * 「选择器 / 地址 / 文本」，点「确认」即复制进剪贴板，粘到对话框里说明怎么改即可。 + */ +(function () { + 'use strict'; + + if (!new URLSearchParams(location.search).has('pick')) return; + + var API = 'http://127.0.0.1:8890'; + try { + if (document.currentScript && document.currentScript.src) { + API = new URL(document.currentScript.src).origin; + } + } catch (e) {} + + /* ---------- 路径与上下文提取 ---------- */ + + /* 生成候选路径；forceNth = true 时每一级都带 :nth-of-type，等于完整树路径 */ + function rawPath(el, forceNth) { + if (!el || el.nodeType !== 1) return ''; + if (el.id && document.querySelectorAll('#' + CSS.escape(el.id)).length === 1) { + return '#' + CSS.escape(el.id); + } + var parts = []; + var node = el; + while (node && node.nodeType === 1 && node !== document.documentElement) { + var sel = node.nodeName.toLowerCase(); + if (node.id) { + sel += '#' + CSS.escape(node.id); + parts.unshift(sel); + break; + } + var cls = Array.prototype.slice.call(node.classList).filter(function (c) { + return !/^(ng-|css-|sc-|is-|has-)/.test(c); + }).slice(0, 3); + if (cls.length) sel += '.' + cls.map(function (c) { return CSS.escape(c); }).join('.'); + var parent = node.parentElement; + if (parent) { + var same = Array.prototype.filter.call(parent.children, function (c) { + return c.nodeName === node.nodeName; + }); + if (forceNth || same.length > 1) sel += ':nth-of-type(' + (same.indexOf(node) + 1) + ')'; + } + parts.unshift(sel); + node = parent; + if (parts.length >= 7) break; + } + return parts.join(' > '); + } + + /* 校验：这条选择器在页面上是不是恰好只命中这一个元素 */ + function matchesExactly(sel, el) { + if (!sel) return false; + try { + var list = document.querySelectorAll(sel); + return list.length === 1 && list[0] === el; + } catch (e) { + return false; + } + } + + /* 先给最短路径；若不唯一，退到每一级都带下标的完整路径 */ + function cssPath(el) { + var base = rawPath(el, false); + if (matchesExactly(base, el)) return base; + var full = rawPath(el, true); + if (matchesExactly(full, el)) return full; + return base; + } + + function breadcrumb(el) { + var names = []; + var node = el; + while (node && node.nodeType === 1 && node !== document.body) { + var n = node.nodeName.toLowerCase(); + if (node.id) n += '#' + node.id; + else if (node.classList.length) n += '.' + Array.prototype.slice.call(node.classList, 0, 2).join('.'); + names.unshift(n); + node = node.parentElement; + } + return names.join(' > '); + } + + var STYLE_KEYS = ['display', 'position', 'width', 'height', 'margin', 'padding', + 'fontSize', 'fontWeight', 'lineHeight', 'color', 'backgroundColor', 'border', 'borderRadius', + 'boxShadow', 'gap', 'flexDirection', 'justifyContent', 'alignItems', 'gridTemplateColumns', 'textAlign']; + + function stylesOf(el) { + var cs = getComputedStyle(el); + var out = {}; + STYLE_KEYS.forEach(function (k) { out[k] = cs[k]; }); + return out; + } + + function attrsOf(el) { + var out = {}; + Array.prototype.forEach.call(el.attributes, function (a) { + if (a.name === 'style' || a.name === 'class' || a.name === 'id') return; + var v = a.value || ''; + out[a.name] = v.length > 120 ? v.slice(0, 120) + '…' : v; + }); + return out; + } + + function textOf(el) { + return (el.textContent || '').trim().replace(/\s+/g, ' '); + } + + function collect(el, sel) { + var r = el.getBoundingClientRect(); + return { + page: location.href, + pageTitle: (document.title || '').trim(), + note: '', + selector: sel, + breadcrumb: breadcrumb(el), + tag: el.tagName.toLowerCase(), + classes: Array.prototype.slice.call(el.classList), + text: textOf(el).slice(0, 200), + attrs: attrsOf(el), + rect: { x: Math.round(r.x), y: Math.round(r.y), w: Math.round(r.width), h: Math.round(r.height) }, + styles: stylesOf(el), + html: el.outerHTML.length > 1500 ? el.outerHTML.slice(0, 1500) + ' ' : el.outerHTML + }; + } + + /* ---------- 剪贴板 ---------- */ + + function legacyCopy(text) { + try { + var ta = document.createElement('textarea'); + ta.value = text; + ta.setAttribute('readonly', ''); + ta.style.cssText = 'position:fixed;top:-1000px;left:-1000px;opacity:0;'; + document.body.appendChild(ta); + ta.select(); + ta.setSelectionRange(0, ta.value.length); + var ok = document.execCommand('copy'); + ta.remove(); + return ok; + } catch (e) { + return false; + } + } + + function copyText(text) { + try { + if (navigator.clipboard && navigator.clipboard.writeText) { + navigator.clipboard.writeText(text).then(function () {}, function () { legacyCopy(text); }); + return true; + } + } catch (e) {} + return legacyCopy(text); + } + + /* ---------- UI ---------- */ + + var host = document.createElement('div'); + host.id = '__ui_picker_host'; + host.style.cssText = 'position:fixed;inset:0;pointer-events:none;z-index:2147483647;'; + document.documentElement.appendChild(host); + var root = host.attachShadow({ mode: 'open' }); + + root.innerHTML = [ + '', + '', + '', + '
未开启', + '已复制 0', + '
', + '
' + ].join(''); + + var box = root.querySelector('.box'); + var tag = root.querySelector('.tag'); + var dot = root.querySelector('.dot'); + var stEl = root.querySelector('.st'); + var cntEl = root.querySelector('.cnt'); + var btnToggle = root.querySelector('.toggle'); + var toast = root.querySelector('.toast'); + var copied = 0; + var active = false; + var hovered = null; + var dialog = null; + + function toastMsg(msg, ms) { + toast.textContent = msg; + toast.classList.add('show'); + clearTimeout(toast.__t); + toast.__t = setTimeout(function () { toast.classList.remove('show'); }, ms || 2600); + } + + function drawBox(el, hit) { + if (!el) { box.hidden = true; tag.hidden = true; return; } + var r = el.getBoundingClientRect(); + box.style.left = r.left + 'px'; + box.style.top = r.top + 'px'; + box.style.width = r.width + 'px'; + box.style.height = r.height + 'px'; + box.classList.toggle('hit', !!hit); + box.hidden = false; + tag.textContent = cssPath(el); + tag.style.left = r.left + 'px'; + tag.style.top = Math.max(0, r.top - 20) + 'px'; + tag.hidden = false; + } + + function isOurs(e) { + return e.composedPath && e.composedPath().indexOf(host) !== -1; + } + + function closeDialog() { + if (dialog) { dialog.remove(); dialog = null; } + } + + function openDialog(el) { + closeDialog(); + + var sel = cssPath(el); + var pageName = (document.title || '').trim() || location.hostname; + var txt = textOf(el).slice(0, 80); + + var d = document.createElement('div'); + d.className = 'dlg'; + d.innerHTML = + '
' + + '
' + + '
' + + (txt ? '
' : '') + + '
'; + + d.querySelector('.hd').textContent = el.tagName.toLowerCase() + + (el.classList.length ? '.' + el.classList[0] : ''); + d.querySelector('.sel').textContent = sel; + d.querySelector('.url').textContent = pageName; + if (txt) d.querySelector('.txt').textContent = txt; + + root.appendChild(d); + dialog = d; + d.tabIndex = -1; + try { d.focus({ preventScroll: true }); } catch (e) {} + + var r = el.getBoundingClientRect(); + d.style.left = Math.min(Math.max(8, r.left), Math.max(8, innerWidth - 446)) + 'px'; + d.style.top = (r.bottom + 12 + d.offsetHeight > innerHeight) + ? Math.max(8, r.top - d.offsetHeight - 12) + 'px' + : r.bottom + 12 + 'px'; + + d.querySelector('.cancel').addEventListener('click', closeDialog); + d.querySelector('.ok').addEventListener('click', function () { + var payload = '选择器：' + sel + '\n网页：' + pageName; + var ok = copyText(payload); + copied += 1; + cntEl.textContent = copied; + drawBox(el, true); + toastMsg((ok ? '已复制：\n' : '剪贴板被拒，内容如下：\n') + payload); + closeDialog(); + try { + fetch(API + '/mark', { + method: 'POST', + headers: { 'Content-Type': 'application/json' }, + body: JSON.stringify(collect(el, sel)) + }).catch(function () {}); + } catch (err) {} + }); + + d.addEventListener('keydown', function (e) { + if (e.key === 'Escape') closeDialog(); + if (e.key === 'Enter' && (e.ctrlKey || e.metaKey)) d.querySelector('.ok').click(); + }); + } + + function onMove(e) { + if (!active || dialog || isOurs(e)) return; + hovered = e.target; + drawBox(hovered, false); + } + + function onDown(e) { + if (!active || isOurs(e)) return; + e.preventDefault(); + e.stopPropagation(); + } + + function onClick(e) { + if (!active || isOurs(e)) return; + e.preventDefault(); + e.stopPropagation(); + openDialog(e.target); + } + + function setActive(v) { + active = v; + dot.classList.toggle('on', v); + stEl.textContent = v ? '拾取中' : '未开启'; + btnToggle.textContent = v ? '关闭' : '开启'; + document.documentElement.style.cursor = v ? 'crosshair' : ''; + if (!v) { drawBox(null); hovered = null; closeDialog(); } + } + + btnToggle.addEventListener('click', function () { setActive(!active); }); + + document.addEventListener('mousemove', onMove, true); + document.addEventListener('mousedown', onDown, true); + document.addEventListener('click', onClick, true); + window.addEventListener('keydown', function (e) { + // Esc 优先：有弹窗就关弹窗，没弹窗就退出拾取模式 —— 焦点在哪儿都生效 + if (e.key === 'Escape') { + if (dialog) closeDialog(); + else if (active) setActive(false); + e.preventDefault(); + return; + } + if (isOurs(e)) return; + var t = e.target; + if (t && (t.tagName === 'INPUT' || t.tagName === 'TEXTAREA' || t.isContentEditable)) return; + if (e.key === 'z' || e.key === 'Z') { e.preventDefault(); setActive(!active); } + }, true); + window.addEventListener('scroll', function () { if (hovered) drawBox(hovered); }, true); + + setActive(true); +})(); diff --git a/product-planning/assets/element-picker/ui-picker-server.js b/product-planning/assets/element-picker/ui-picker-server.js new file mode 100644 index 0000000..69d5c53 --- /dev/null +++ b/product-planning/assets/element-picker/ui-picker-server.js @@ -0,0 +1,125 @@ +#!/usr/bin/env node +/** + * ui-picker-server.js —— 极简「页面元素拾取」服务（零依赖） + * + * 干什么：给浏览器里的拾取器提供一个落脚点 —— + * 页面点选元素后，把「选择器 / 网页 / 文本 / class / 关键样式 / HTML 片段」 + * 追加写进本技能目录下的 marks/_ui-marks.json，供 AI 读取后精确改代码。 + * + * 起法： node ui-picker-server.js [端口] （在本目录下执行，默认 8890） + * 页面： + * URL 带 ?pick 才激活；按 Z 切拾取模式；点元素 → 确认窗 → 「确认」 + * + * 端点： + * GET /picker.js 注入脚本 + * POST /mark 存一条标记（追加写盘） + * GET /marks 读回全部标记（JSON） + * POST /clear 清空标记 + * GET /health 存活检查 + */ +const http = require('http'); +const fs = require('fs'); +const path = require('path'); + +const PORT = parseInt(process.argv[2], 10) || 8890; +// 存档跟技能一起放，搬到哪都自洽 +const OUT_DIR = path.join(__dirname, 'marks'); +const OUT_FILE = path.join(OUT_DIR, '_ui-marks.json'); + +function readMarks() { + try { + const raw = fs.readFileSync(OUT_FILE, 'utf8'); + const obj = JSON.parse(raw); + return Array.isArray(obj.marks) ? obj : { updated: '', marks: [] }; + } catch { + return { updated: '', marks: [] }; + } +} + +function writeMarks(obj) { + fs.mkdirSync(OUT_DIR, { recursive: true }); + obj.updated = new Date().toISOString(); + fs.writeFileSync(OUT_FILE, JSON.stringify(obj, null, 2), 'utf8'); +} + +function send(res, code, body, type) { + res.writeHead(code, { + 'Content-Type': type || 'application/json; charset=utf-8', + 'Access-Control-Allow-Origin': '*', + 'Access-Control-Allow-Headers': 'Content-Type', + 'Access-Control-Allow-Methods': 'GET,POST,OPTIONS', + 'Cache-Control': 'no-store', + }); + res.end(body); +} + +function readBody(req) { + return new Promise((resolve, reject) => { + let buf = ''; + req.on('data', (c) => { + buf += c; + if (buf.length > 8 * 1024 * 1024) reject(new Error('body too large')); + }); + req.on('end', () => resolve(buf)); + req.on('error', reject); + }); +} + +const server = http.createServer(async (req, res) => { + const url = new URL(req.url, `http://127.0.0.1:${PORT}`); + + if (req.method === 'OPTIONS') return send(res, 204, ''); + + if (req.method === 'GET' && url.pathname === '/health') { + return send(res, 200, JSON.stringify({ ok: true, skill: __dirname, file: OUT_FILE, count: readMarks().marks.length })); + } + + if (req.method === 'GET' && url.pathname === '/picker.js') { + return send(res, 200, fs.readFileSync(path.join(__dirname, 'picker.js'), 'utf8'), 'application/javascript; charset=utf-8'); + } + + if (req.method === 'GET' && url.pathname === '/marks') { + return send(res, 200, fs.readFileSync(OUT_FILE, 'utf8').toString()); + } + + if (req.method === 'POST' && url.pathname === '/mark') { + try { + const body = JSON.parse(await readBody(req)); + const store = readMarks(); + const item = { + id: store.marks.length + 1, + at: new Date().toISOString(), + page: body.page || '', + note: body.note || '', + selector: body.selector || '', + breadcrumb: body.breadcrumb || '', + tag: body.tag || '', + classes: body.classes || [], + text: body.text || '', + attrs: body.attrs || {}, + rect: body.rect || null, + styles: body.styles || {}, + html: body.html || '', + }; + store.marks.push(item); + writeMarks(store); + console.log(`[mark #${item.id}] ${item.selector} ← ${item.note}`); + return send(res, 200, JSON.stringify({ ok: true, id: item.id, total: store.marks.length })); + } catch (e) { + return send(res, 400, JSON.stringify({ ok: false, error: String(e.message || e) })); + } + } + + if (req.method === 'POST' && url.pathname === '/clear') { + writeMarks({ updated: '', marks: [] }); + return send(res, 200, JSON.stringify({ ok: true, total: 0 })); + } + + return send(res, 404, JSON.stringify({ ok: false, error: 'not found' })); +}); + +server.listen(PORT, '127.0.0.1', () => { + console.log(`元素拾取服务已启动: http://127.0.0.1:${PORT}`); + console.log(`页面引入: `); + console.log(`标记落盘: ${OUT_FILE}`); +}); diff --git a/product-planning/references/stage-delivery/assets/video-capture/ATTRIBUTION.md b/product-planning/assets/video-capture/ATTRIBUTION.md similarity index 100% rename from product-planning/references/stage-delivery/assets/video-capture/ATTRIBUTION.md rename to product-planning/assets/video-capture/ATTRIBUTION.md diff --git a/product-planning/references/stage-delivery/assets/video-capture/SKILL.md b/product-planning/assets/video-capture/SKILL.md similarity index 100% rename from product-planning/references/stage-delivery/assets/video-capture/SKILL.md rename to product-planning/assets/video-capture/SKILL.md diff --git a/product-planning/references/_留痕/N6-20261016/SKILL.md b/product-planning/references/_留痕/N6-20261016/SKILL.md new file mode 100644 index 0000000..8c5a674 --- /dev/null +++ b/product-planning/references/_留痕/N6-20261016/SKILL.md @@ -0,0 +1,305 @@ +--- +name: product-planning +description: 产品规划总入口（唯一入口），四段式调度：① 产品需求 ② 产品功能 ③ 界面交互 ④ 原型说明文档。四段以 references/stage-* 承载，本文件是总调度与约束。可整段跑也可只调一段。当用户要做产品规划、从零做新产品、只做某一阶段、或不知道从哪开始时调用。 +--- + +# 产品规划总入口 + +> 本 skill 由模型按需自动加载，没有斜杠命令。对话里还没定出对象时，先按「项目与路径约定」定出 `<项目>`；定不出来就停下问用户，不要自行假设。 + +## 用途 + +用户丢来一句模糊想法（例如「我要做一个 AI 短剧分镜画布」）时，本 skill 判断该走哪一段，只做那一段的最小必要工作，产出可交付物，再推进到下一段。 + +本文件管调度与约束。各段怎么做，写在 `references/stage-*` 各自的文件里。 + +## 四段结构（可整段跑，也可只调一段） + +| 段 | 回答的问题 | 子步 | 调用 | 产出物 | +|---|---|---|---|---| +| **① 产品需求** | 要做的东西凭什么成立：什么问题、为谁、为什么值得做 | 1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景 | `stage-discovery` | `docs/pm/<项目>/research/*`。其中 1b 交两种体例：`research/1b-竞品分析.md`（汇总对比）＋ `research/1b-独立分析/<竞品名>.md`（独立分析） | +| **② 产品功能** | 要做哪些功能、什么不做、长成什么骨架 | 2a 产品功能 / 2b 界面布局 | `stage-requirements` | `docs/pm/<项目>/prd/2a-产品功能.md` 与 `prd/2b-界面布局.md`（两份） | +| **③ 界面交互** | 长什么样、怎么操作 | 3a 视觉规范 / 3b 原型 / 3c GPT参考版 / 3d 审查打磨 | `stage-delivery` | `docs/pm/<项目>/DESIGN.md`、`docs/pm/<项目>/ui/*.html`、`docs/pm/<项目>/ui/3c-GPT参考版.md` | +| **④ 原型说明文档** | 现有原型怎么用、每条功能落在哪个页面、坏了怎样、怎么核对（文档按六节铺：页面结构 → 功能清单 → 使用场景 → 操作流程 → 跨页与界面状态 → 待确认与偏离） | 4a 场景盘点 / 4b 说明区 / 4c 演示引导（可选） | `stage-proto-doc` | 原型内嵌说明区 ＋ 独立产品文档 `docs/pm/<项目>/ui/产品文档.html`（两份共用同一套 P 页面／S 场景／F 功能／J 二级功能编号） | + +四段只通过落盘文件耦合。段间交接口如下，这是唯一的契约，越界即失效： + +| 交接 | 由谁给 | 给什么 | 给到哪为止 | +|---|---|---|---| +| ① → ② | ① | 问题定义、需求澄清决策表（含 grill 压测的 B 节：做成什么样 / 哪些情况不成立 / 状态怎么流转）、取证结论（1b 汇总对比体 ＋ 1b 独立分析体、1c 用户画像）、产品定位、《使用场景》＝用户故事（②段功能的直接推导依据） | 功能清单归②段产出，1a 写到需求与形态为止 | +| ② → ③ | ② | 功能清单（每条带优先级 ＋ 状态流转）、界面布局（有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系）、每页主操作、信息承载分档（主屏常驻 / 可点入） | 视觉归③段。骨架必须给全，骨架不给全，③段就一版一个样 | +| ③ → ④ | ③ | 已跑通的单文件原型 HTML（页面、模块、控件、状态、交互、跳转、反馈＝界面事实的唯一依据） | 说明区与独立产品文档归④段；⛔ ④段不重新规划产品、不重新设计界面 | + +> 口径：②段钉骨架，③段做皮肉。两侧逐行对照与用户原话只在②段 `references/stage-requirements/SKILL.md` 的 §②—③ 交接口 定义一次 —— 本入口不复述。要点两条：②段要给全「归②段」列；③段不许增删移动板块，缺板块回②段改。 + +> ②→③ 最容易搞坏。旧病灶：②段说「必须能读到」，③段读成「必须常驻主屏」，五类信息就全铺一屏成了信息墙。分档表把「读到」明确成「一次点击内可达」，防的就是这句歧义。骨架是灰块（有哪些块、什么顺序），③段给的是视觉与交互实现（排版、点哪有什么反馈、空态、响应式）。两件事各管一维，③段不会退化成照抄。 + +> 四段各占一个词，互不共用（2026-10-02 定）：产品 / 功能 / 界面 / 说明。改段名前先对照这张表；两个段名里出现同一个词，边界一定在漂。旧名「调研与方案 / 需求与结构」都含「需求」，③段旧名里的「交付」是三段共有的属性，都属名实不符，已改。 +> 🔴 **④段的沿革（2026-10-14 → 10-15）**：10-14 按用户令删掉**旧版**④段 —— 旧做法是往原型 HTML 注入说明区注解层（状态 → 场景 → 从左到右流程图 → 功能作用/输入边界/异常情况 三段 → 逐步骤演示引导），实测没法用，整段连方法论一并撤掉。10-15 用备份里的**新版**④段装上：改成「解释与记录现有原型」，交**两份产物**（原型内嵌说明区 ＋ 独立产品文档 `docs/pm/<项目>/ui/产品文档.html`），内容先按四块＋附录铺，随后整套同步成**六节**（页面结构／功能清单／使用场景／操作流程／跨页与界面状态／待确认与偏离），编号改用 P 页面／S 场景／F 功能／J 二级功能，并带一份现成模板 `references/stage-proto-doc/assets/产品文档模板.html`。判据正文在 `references/stage-proto-doc/`，⛔ 旧版那套（状态轴、三段必填、逐步骤演示）不再使用。 +> ①叫「产品需求」不叫「需求调研」：该段产出 `research/1a-需求文档.md`、`1b-竞品分析.md`、`1c-用户画像.md`，也产出 `1d-产品策略.md`、`1e-使用场景.md`，「调研」二字盖不住后半截。 +> ⭐ 1b 是①段唯一交两种体例的子步：独立分析体 `research/1b-独立分析/<竞品名>.md`（竞品池每一个一份），汇总对比体 `research/1b-竞品分析.md`（恒一份）。职责边界与定案原话见 `references/stage-discovery/references/competitor-analysis.md` §0.4。 + +⭐ `grill-me` 全场只有①段一份（2026-10-06 用户定案）：①段那份按 A / B 两节提问，火力点划分、节次归属与定案原话见 `references/stage-discovery/references/grill-me.md` —— ⛔ 本入口不复述。B 节结论落进 `research/1a-需求文档.md`。 + +⭐ ②段产出两份（2026-10-06 收窄，2026-10-07 定为两份）：`prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 ＋ 状态流转）与 `prd/2b-界面布局.md`（页面关系 ＋ 页面内板块布局）。定案原话与理由见 `references/stage-requirements/SKILL.md` 开头。 + +（交接口反转前的口径、②段收窄前的产出清单与去向 → `references/_留痕/③段与总入口-旧口径.md`） + +⚠️ ①段功能按「使用场景」组织（一条场景可跨多个页面），不按页面组织。 + +段内的子步顺序、方法论文档、硬约束、完成标准，都在各段自己的 `SKILL.md` 与 `references/` 里。 + +①段 1a 需求文档：全程最先做，且只做一次。用 grill-me 与用户互动，产出 `docs/pm/<项目>/research/1a-需求文档.md`（开头写清做什么 / 为谁 / 不做什么，往下是决策表）。 + +## 项目与路径约定（单一真源） + +> 四段全部遵守本节。各段 `SKILL.md` 与 `references/` 里出现 `docs/pm/...` 时，`<项目>` 一律指本节定义的 slug。 + +### `<项目>` 是什么 + +项目 slug 用小写字母、数字、连字符（例 `my-tool`、`video-canvas`）。它就是 `docs/pm/<项目>/` 这一层的目录名，一个字都不能差；各段产物都挂在它下面 —— ①段 `research/`、②段 `prd/`、③段与④段 `ui/`、跨段 `专题/`。 + +### slug 怎么定（按序取第一个成立的） + +| 序 | 条件 | 取值 | +|---|---|---| +| 1 | 用户在当前会话里明确说了项目名 | 该名字 slug 化 | +| 2 | `.registry/current-project` 存在且非空 | 其内容 | +| 3 | `docs/pm/` 下恰有一个非 `_` 开头的目录 | 该目录名 | +| 4 | 以上都不成立 | 停下问用户 | + +写任何文件之前先核对：目标路径里的 `<项目>` 段与按上表得出的 slug 是否一致。不一致就停下说明，不要「先写了再说」——猜错会把产物写进别的项目，事后极难拆干净。 + +### 产物落哪 + +| 段 | 路径 | +|---|---| +| ① 产品需求 | `docs/pm/<项目>/research/` | +| ② | `docs/pm/<项目>/prd/` | +| ③ | `docs/pm/<项目>/DESIGN.md`、`docs/pm/<项目>/ui/*.html`、`docs/pm/<项目>/ui/3c-GPT参考版.md` | +| ④ | 原型内嵌说明区（写进 `docs/pm/<项目>/ui/*.html` 自身）＋ 独立产品文档 `docs/pm/<项目>/ui/产品文档.html` | + +### 文档的两态：当前版与过期版 + +用户令（2026-10-11 逐字）：「**应该有文件夹 专门归档过期文档， 当前文档 统一放在方案文件夹中**」。 + +🔴 **方案文件夹** ＝ `docs/pm/<项目>/` 这一层 —— 它下面放的全是**当前权威版**：①段 `research/`、②段 `prd/`、③段 `ui/`、跨段 `专题/`，另加一份 `索引-当前权威版.md` 当入口。 +🔴 **归档文件夹** ＝ `docs/pm/<项目>/归档-过期版/` —— 被顶替下来的旧版全放这里，命名 `<原名>__<来源目标短哈希>.<扩展名>`（例 `2b-界面布局-新版__fc471a.md`）。 + +**每个目标收口时做四步**： +1、本目标的权威文档**覆盖**方案文件夹里对应的那一份。 +2、被顶替的旧版**移进** `归档-过期版/`，按上面的命名补上来源短哈希。 +3、更新 `索引-当前权威版.md` 里对应行的大小与日期。 +4、执行区（`执行会话/目标-*/` 这类过程目录）里的原件**保留** —— 它既是过程留痕，也是台账 `artifact` 指向的地方，搬空会让回查断链。 + +**为什么要有这条**（避坑依据 · 2026-10-11 实测）：同一个 `2a-产品功能` 在 6 个目标目录里各有版本、`2b` 有 7 个，光看文件名与字节数分不出谁新；而 `docs/pm/` 下早先那次归档又停在旧版（`2b` 只 52 256 B，最新已是 52 643 B）⇒ 用户问「很多新老方案都在文件夹中，后续根据方案细化产品界面，如何找得到对应的方案」。判断某份文档的当前版，**只看方案文件夹**；问「当时为什么这么定」才去归档文件夹翻。 + +### DESIGN.md 为什么在项目目录、不在仓库根 + +`DESIGN.md` 是③段的绑定视觉规范，一个项目一份，③段按当前项目的 slug 去读它。仓库根只能放一份，多项目会互相覆盖，所以一律放 `docs/pm/<项目>/DESIGN.md`。 + +推论（硬规则）：读 `DESIGN.md` 时，路径必须由本节定义的 `<项目>` slug 拼出，不许用「当前工作目录碰巧有 DESIGN.md」这类推断。仓库根不放任何项目的 `DESIGN.md`。 + +## 工具选择规则（防止选错，最重要的一节） + +> 下表是选型总则。这些工具都已封装在对应段内，本文件只负责让你不选错；具体调用路径见各段 `SKILL.md`。 + +| 要什么 | 用谁 | 别用 | +|---|---|---| +| 页面设计全链（规范 → 原型 → 审查） | ③段 `stage-delivery` 自己的 D0→D5 流水线 | 另找风格库，或自己手搓一套 token 与门禁 | +| 评审用的可点原型 / 生产级前端页面 | ③段 3b（按 D2 构建，单文件 HTML 交付）。先判页型：营销页取③段 §供给·版式骨架 的可选档，工具型页面取其默认档 | 不判页型就套可选档种子——那是营销落地页骨架，会把后台做成营销页 | +| 设计规范文件 | ③段 3a 生成 `DESIGN.md`（令牌表取自③段选定套，见③段 §供给·定调与令牌；再加该项目②段的界面需求） | 凭空编一套 token | +| 架构图 / 流程图 / 时序图 | `diagram-design` | 手写 Mermaid | +| 状态迁移的守卫、副作用、并发 | `state-machine` | 指望 diagram-design 覆盖这些 | +| 审美方向 / 风格定调 | ③段 §供给·定调与令牌 的默认档里选一套（可选档亦见该处），读候选套按页面类型挑。⛔ 每次只选一套 | 「米白＋衬线＋陶土色」这类默认审美，或凭感觉编 | +| 多方向比选 / 独立评审打分 | ③段 §供给·多方向比选 与 §供给·独立评审协议 | 拿它的评分循环替代本段 Gate-1/2/3 | + +③段的页面设计供给 —— 默认主线、定调与令牌、版式骨架、工艺数值判据、独立评审协议、多方向比选，共六档；各档的默认来源 / 可选来源 / 路径只在③段 `references/stage-delivery/SKILL.md` 的 §供给 定义一次，本入口不复述，要改供给只改那一块（2026-10-08 起）。`oil-ui-pro` 是界面设计方法论：五步流程（探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付），加风格对比页与截图工具；它自带联网版本检查与自动更新，是用户明确要求全量搬入的例外项（既有纪律是「依赖外部服务一律不收」），已记录在案，不扩散。 + +默认走 `oil-ui-pro` 主线，不与可选档缝成一条流水线：可选档只在 §供给 里列，选了才作补强（多一路定调候选、多一套工艺数值判据），不选也不影响开工。 + +四样东西供给件里都没有对应，由 `stage-delivery` 自己扛：设计契约十二字段、结构骨架、交互清单、工具型版式库。 + +页型分流（2026-10-05 新增）：③段 §供给·版式骨架 的可选档是营销落地页向，工具型页面照它做会长出「标题上下各一行小字」的三段式（骨架名单与理由见③段 `references/stage-delivery/references/layouts-tooling.md` 开头）。本项目实测踩过这个坑，结构判据全绿也拦不住。所以③段 D0 必须先判页型，工具型页面版式一律走 §供给·版式骨架 的默认档。 + +只读一处来源：同一条判据若在默认档与可选档各有一份且口径不同，以本项目追加条为准 —— ⛔ 但追加条不得放宽基础层（`oil-ui-pro` 是基础层、其余是叠加层，分层规则见③段 §供给），并在 runbook §3.4 显式标注「本项目追加」。 + +DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec` 四个子命令，目前是 alpha（v0.4.0）。非 TTY 的管道里可能不回显输出，需在真实终端里确认。本机实测该命令完全不可用，不要拿它当校验关卡；改由 D3 收口与 D5 终检按真实像素人工复测对比度（判据见③段 §供给·工艺数值判据 里配色那一份）。原两把门禁脚本（静态文案检查 / 渲染机检）已随旧主干从磁盘移除，当前没有机器复现，结论只能记「人工判定」，不得写成「脚本已通过」。 + +## 可调用工具（自然语言触发） + +> 两个独立工具，按用户说法直接触发，产物落项目目录。`design-capture` 随③段携带（装在③段 `references/stage-delivery/assets/` 下）；`video-capture` 2026-10-11 已独立成全局技能（装在**技能根**下的 `video-capture/`），跨段复用。两者都不单独成段。 + +| 用户说 | 触发工具 | 做什么 | 产物 | +|---|---|---|---| +| 「分析 XXX 视频」「把这个视频抽帧」「拆一下这条视频的画面」 | 全局技能 `video-capture` | 取视频（本地文件 / 直链 URL / 平台页经浏览器下到本地）＋ 抽帧（双因素 ＋ 首尾 ＋ 补帧） | 关键帧 `c_<序号>_<真实秒数>s.jpg` ＋ `frame_times.json`（供①竞品分析、③视觉参考） | +| 「获取 XXX 网站的设计风格」「抓这个网站的风格/组件/配色」 | `stage-delivery/assets/design-capture/` | 抓网页设计系统（色彩 / 排版 / 组件），生成样式模板 | 一套 `design-system-<名>/`（与 `design-system-tiaoyue` 同构，可直接被③段 D1 选用） | + +两者都独立可单跑：`video-capture` 只依赖 `ffmpeg`（权威件＝全局技能 `video-capture`；原 `stage-delivery/assets/video-capture/` 只留交接说明，脚本迁至 `references/_留痕/video-capture-已独立-20261011/` 留档）；`design-capture` 只依赖本机 Chrome（CDP）＋ `vendor/` 里搬运的抽取脚本，不需要任何外部服务在场。用法与边界见各自 `SKILL.md`，来源与署名见各自 `ATTRIBUTION.md`。 + +触发时机：①②段拆竞品视频用全局技能 `video-capture`；③段要新建样式或拆参考站用 `design-capture`。 + +两个工具都只做合规最小集：不抓平台页内视频，不调付费接口；抽取结果须先目视比对再采用。 + +## 进入方式 + +| 你说什么 | 模式 | 从哪开始 | +|---|---|---| +| 「规划 XX」「从零做 XX」 | 全流程（自动处理） | `stage-discovery` → `stage-requirements` → `stage-delivery` → `stage-proto-doc`，一路跑完，段间不停下来问（含①段末） | +| 「先确认方案」「跑完方案停下等我」「规划 XX，先给方案」 | 方案确认 | 同一套四段，唯一差别是①段末停下等你确认方案，确认后才进②③④ | +| 「只做产品需求」「只做产品功能」「只做界面交互」「只做原型说明文档」 | 单段 | 只调对应那一个 stage skill，不展开其他段 | +| 已有②段，要出原型 | 单段 | 直接调 `stage-delivery`，从它的 3a 起 | +| 已有原型，要补说明 | 单段 | 直接调 `stage-proto-doc`，从它的 4a 起 | +| 只问某个单点 | 单段 | 不跑任何段，在对应 stage skill 内点名子步，或直接说要看哪份方法论 | + +「只调一段」成立的原因：四段之间只通过落盘文件耦合，没有隐式状态。 + +- ②只读 `docs/pm/<项目>/research/*`；缺失时标注 `【假设】`继续，不催促回补① +- ③只读 `docs/pm/<项目>/prd/*`；缺失时同样标 `【假设】`继续 +- ④只读 `docs/pm/<项目>/ui/*.html`（界面事实的唯一依据），另按需读 `docs/pm/<项目>/prd/*` 与 `research/1a-需求文档.md` 定业务意图；缺失时标 `【假设】`继续，并在段末偏离单里写明 + +## 执行规则 + +只有三种模式，没有第四种： + +| 模式 | 段之间 | 段之内 | +|---|---|---| +| 全流程（自动处理） | 一路跑完，段间不停下来问（含①段末）。每段结束按「标准收尾格式」输出一段报告，输出完即刻进下一段 | 子步之间不反问，做完直接进下一个子步 | +| 方案确认 | 与全流程完全相同，只有一处不同：①段末停下等你确认方案；确认后②③④一路跑完、段间不停 | 同上 | +| 单段 | 不涉及 | 不越界，不催促回补前段 | + +这两条是全流程模式下的两个独立分支，不要混：全流程（自动处理）没有①段末的强制停；「停下等确认方案」只在「方案确认」模式下发生。二选一由用户定（界面里点【生成原型和文档】时选「自动处理」或「先确认方案」，或在会话里直接说明）；用户没明说时按自动处理走，不要在自动处理模式下自作主张停下来问。 + +「停下」指什么，不要读成「每一步都要反问用户」。只有这四种情况才停： + +1. 信息不足且查不到，必须用户给（如「项目与路径约定」slug 第 4 条）——停下问 +2. 破坏性 / 不可逆动作——二次确认 +3. 用户显式要求某个子步做完停下 +4. ①段末的方案确认（仅「方案确认」模式）——把方案摆给用户：做什么 / 不做什么 / MVP 边界 / 未复核的 `【假设】`，明说「等你确认方案，确认前不进②段」 + +段末报告：全流程（自动处理）模式下，所有段（含①）都只输出报告，不提问、不等回答；方案确认模式下①段是唯一例外，其余段同样只输出报告。 + +①段末的确认是回环，不是一次问答（仅「方案确认」模式）：用户看到方案后可以提问题要求改，可能多轮，每轮的「问题＋怎么改的」都要留痕、不得覆盖上一轮；改完由用户显式说「确认方案」才算过闸门。该模式下，没拿到用户确认的方案不得当成既定事实带进②段——这是实测踩过的坑：②段拿着未经确认的方案往下跑，把用户已拍板的需求裁掉了。 + +其余规则： + +- 声明制（全段适用，不止③段）：开工前、每进一个子段或子步、每处偏离，都要声明三件事——当前在哪、依据哪个文件的哪一节、产出落哪；偏离当场写明原因与影响，段末附偏离单。不许静默偏离。实测踩过的坑：③段 3b 交付了原型却没走当时声明的主流程、没读依据文件，也没当场说，用户追问「基于哪个 skill」才知道。 +- 不做八股：不介绍方法论来源，不列人名，不复述框架历史，直接给结论。 +- ⭐ 内容准则：一切落盘文字都要先过「说人话」这一关（2026-10-07 用户定案，同日扩大到规则文件）。用户原话：「当作第一步 和 第二步 生成文档时 必须遵循的内容准则」「不管是写规则 还是 写文档 都要严格按照说人话的技能去执行」。 + - 适用面两类都算，只改产出不改规则等于半改。一是产出文档：`research/1a-需求文档.md` 到 `1e-使用场景.md`（5 份）、`research/1b-独立分析/`（独立分析体）、`prd/2a-产品功能.md` 与 `prd/2b-界面布局.md`（2 份）。二是规则本身：本技能包内的一切落盘文字，`SKILL.md`、`references/**`、模板与清单。 + - 判据来源（单一可信源，本文件不复述模式清单）：**只有 `humanizer` 一份，且只用它的英文正式目录** —— `<技能根>/humanizer/references/patterns.md` 的 **P1–P55**（内容 8／语言与风格 10／沟通 3／填充与模糊 9／新兴 13／工艺与取证 12）。另有 5 种口吻档（casual / professional / technical / warm / blunt）。 + - 🔴 **判据一律用英文目录（2026-10-15 用户令）**：中文附录 `patterns.zh.md`（ZH1–ZH15）**只作参考线索，⛔ 不作判据** —— 作者自标「实验性、未经中文母语写手校验、不应被当作已验证的规则」。原中文版 `humanizer-zh` 的 24 条与五维 50 分表随该技能删除一并停用作废。 + - 门槛（2026-10-15 改）： + · **英文产出**：可读 `--score` 的 0–100 AI 痕迹密度分（越低越像人；上游 pre-commit 的拦截线是 40），本包不设硬阈值，分数写进段末报告。 + · **中文产出**：⛔ 不采信自动分数 —— 该打分器按 `[.!?]` 切句、按 `[a-z0-9]` 切词，中文 `。！？` 不切句、汉字零词，分数实际在测「文件里有多少拉丁字符」（实测：同一段中文把 `。` 换成 `. ` 分数不变；零拉丁字符的中文直接判 `No text`）。改按 **P1–P55 逐条人工对照**，再跑 `--check-facts` 保真（它只抽数字／日期／版本／URL／路径／标识符，中文同形可用）。对照结果与事实存活数写进段末报告，命中项不对完不许落盘。 + - ⛔ 取不到判据来源时（2026-10-08 补）：两份技能都不在位或读不到 ⇒ **不许凭感觉判「这条够人话」**。在段末报告与 `3d-审查报告.md` 里明写「无判据来源，本项未判」，按与 §供给·工艺数值判据 的「证据缺口」同一口径处理。 + - 五条核心原则（2026-10-15 起**就地固化在本包**；原引自已删除的 `humanizer-zh`《核心规则速查》，英文版 `humanizer` 的 Quick reference 没有等价条目，故不再指向外部）：删填充短语（开场白、强调性拐杖词）；打破公式结构（二元对比、戏剧性分段、修辞性设置）；变化节奏（长短交错，两项优于三项，段尾多样）；信任读者（直接陈述事实，跳过软化、辩解、手把手引导）；删金句（读起来像可引用的话，就重写它）。 + - 🔴 **适用面要划清（2026-10-15 排查后立）**：本包只取这份技能里**「去 AI 味」那一半**，⛔ 不取**「注入个性」那一半**。 + 取这些：英文模式目录 `references/patterns.md` 的 P1–P55、就地固化的五条核心原则、禁用清单。 + 不取这些：`Soul Injection Techniques` 整节（11 条）—— 它明写「有观点、别只报告事实」「用具体感官／体验细节代替抽象说法」「允许跑题与题外话」「结尾不必收束」「用 imperfect start 开场」，与本包产出要的**客观书面说明文**正好相反（照它写会出乱比喻、口水话、不能简明扼要）。该节第 3 条自带的示例就是「凌晨两点冷咖啡和看不懂的堆栈」这种感官化写法。 + 口吻档：本包产出**固定取 `technical`**（精确用词、一句一个意思、⛔ 无比喻除非确能澄清），⛔ 不用 casual／warm／blunt。 + ⛔ **已停用**：原中文版 `humanizer-zh` 及其五维 50 分表（该技能 2026-10-15 已整包删除，判据不再走它）。 + - 🔴 **同一件事更严的那份说了算**：④段的 `references/doc-language-spec.md`（客观书面说明文 ＋ 逐条禁用清单）是本包最严的一份语体规范；任一段落盘文字与它冲突，**以它为准**。 + - 交付留证：产出文档在段末报告里写明「已过内容准则，评分 X/50」；改规则文件时，在当日 memory 里记下这一关过了。 +- 只调一段时不越界：用户说「只做第 N 段」，就跑该段，不展开其他段，也不用「你还没做调研」去催促。 +- 提问上限 3 个：其余用合理假设，并在文档里标注 `【假设】`。例外是 `grill-me` 提问模式，不受此限（①段的「需求澄清」与②段的「需求压测」各一次），该模式的价值就是穷尽提问；此时须先声明「将连续多轮提问」，退出后恢复本约束。 +- 反问优先，允许自动补全：`grill-me` 的默认动作是把问题抛给用户并附推荐答案。用户说「你定」、连续两轮不回应、或属事实类问题时，模型自行给答案并标 `【假设】`，换来「不卡住」；但每轮结束要汇出待复核清单，未经复核的 `【假设】` 不得在下游当事实用。 +- 停线规则（**单一真源，全包只在本节写一次**，各段一律引用、⛔ 不复述）：只有三种情况停 —— ① 信息不足且查不到；② 破坏性／不可逆动作；③ 用户显式要求。 +- MVP 边界优先：任何阶段都先回答「第一版做什么、不做什么」。 +- 必须落盘：产出写入文件，不要只在对话里输出。 +- 无来源就标注：任何查不到来源的数据都标为「估算」并写明口径，不编造数字当事实。 +- 禁止长文：单份产出物默认一页纸（≤120 行），超长必须拆分。 +- ⭐ 落盘产出的排版（2026-10-14 用户令，原话「标题周围写小字的怪毛病 彻底改掉」）：元信息（条数、口径、读法、状态）写进表格的列、条目的字段或表头；标题旁边、标题下面、标题后面都只放标题本身。④段的 `references/doc-language-spec.md` 另有一份更细的，冲突以那份为准。 +- 🔴 路径写相对或占位（2026-10-14 用户令）：本包内一切文字（`SKILL.md`、`references/**`、脚本与注释、模板）引用**本技能自己或同根技能**的位置时，写相对形态 —— 同根技能写 `<技能根>/<技能名>/`，本包自己的文件写包内相对路径（如 `references/stage-delivery/`）。只有**跨根引用**（工作区根、文档库根、本机软件安装位这类从本包推不出来的别的根）才落到具体位置，且优先读环境变量（`DSH_WS_ROOT` / `DSH_DOCS_ROOT` / `WORKBUDDY_BIN_ROOT`）。原因：技能根的位置随环境变（全局技能根还是工作区技能根、用户名与盘符各不相同），写死了换台机器就是死路径，跨环境会整片报错。 + +## 征询外部模型（GPT）的提问口径（单一真源） + +> 🔴 2026-10-15 用户令，逐字：「问 GPT 的时候 只需要说明 关键背景情况和需求询问，禁止带入过多细节上下问造成干扰」。本包内一切向外提问的动作都按本节写；③段 3c 的提问模板是本节的一个实例，⛔ 不在别处另立一套口径。 + +- **要写三样**：① 场景一句（这是什么、要解决什么）；② 手上已有什么（只列与本次提问有关的）；③ 想问哪几个问题（逐条列，一条一个问点，末尾一句收口）。 +- **判据**：背景写到「对方能接住这个问题」为止 —— 少了这句，对方就问不出对的问题吗？问不出才留，问得出就删。 +- **⛔ 不带**：过程留痕、已废弃做法的设计细节、「我们为什么这么做」的来龙去脉、内部硬约束清单、字段与文件清单。这些会把回答拖进细节纠缠，占掉本该用在核心问题上的注意力。 +- **为什么**（避坑依据 · 2026-10-14 实测）：为问「原型说明文档该怎么写」，先铺了 1 500 余字的背景（含已废弃做法的 5 个设计点、4 条硬约束、7 个问题）⇒ 细节量压过问题本身。 +- **留痕**：提问原文与回答原文都要落盘；提问按本节写，⛔ 不把本机路径当内容（外部模型看不到本机路径，要么逐字内联、要么上传文件）。 + +## 产出文档开头必须有图（单一真源） + +> 2026-10-15 用户令，逐字：「产品规划页面 所有文档前面都要画图」。各段一律引用本节，⛔ 不在段内另写一套口径。 + +- 每份落盘文档**第一屏就给一张图**：图放在标题之后、正文之前 —— 不读正文也能先拿到全貌。 +- 图是**正文内容**，⛔ 不写成标题旁边或标题下面的注解小字（与上面那条排版红线同一件事）。 +- 图要**表达结构或流程**（二选一或兼具）—— 一张图看完就知道「由哪几块组成、怎么连起来」或「一件事分几步走」；⛔ 不做纯装饰性配图。 +- 图表达这份文档**覆盖的东西之间的关系**，按段定画什么： + · ①段（`research/` 五份）—— 画对象与流向：为谁解决什么、信息从哪来到哪去。 + · ②段（`prd/` 两份）—— 画页面骨架：有哪几页、每页几个板块、跨页关系怎么走。 + · ③段（`ui/` 下的产物与 `DESIGN.md`）—— 画页面结构与操作动线：用户办成一件事实际经过哪几页、每页做什么、哪里要来回跳。 + · ④段（产品文档）—— 画页面结构图（各页面与其下的功能编号）＋ 用户路径：各场景怎么串起来。 +- 画图用 `diagram-design`，⛔ 不手写 Mermaid（判据见「工具选择规则」那张表）。 +- 图里每格写清名字、线标方向；图与正文互相对得上 —— 正文新增或改了结构，图要跟着改，两处不许各说各的。 + +## 每段的标准收尾格式 + +``` +## 本段结论 +- （3-5 条，可直接决策的话） + +## 已落盘 +- ... + +## 待确认（最多 3 条） + +## 建议下一步 +→ 用 完成 <具体事> +``` + +## 反面清单 + +- 为一个小功能跑完整调研 +- 输出长文却给不出一个结论 +- 跳过「不做什么」 +- 用户只问单点，却强行拉进全链路 +- 把估算数据写成确凿事实 +- 跳过③段 D0 的 Gate-1（未定死令牌表与设计契约）就开写页面代码 +- 在 `grill-me` 提问模式下仍套用「提问上限 3 个」，把提问做成走过场 +- 只跑一次 `grill-me`：①没定义需求就去取证，或②拿①段的需求定义代替功能压测直接写②段 +- 把自动补全当默认动作：用户没说话就替用户拍板，还没标 `【假设】`、没进待复核清单 +- 手写 Mermaid 代替 diagram-design，手写 token 表代替 DESIGN.md +- 绕过四段自己手搓，或重写它们的内容（该调 `stage-*` 就调） +- 把供给件的内部路径按本 skill 目录去拼，或改它们的正文 —— 供给件指③段自带的 `oil-ui-pro`，以及 §供给 各档落在 `assets/` 下的件（它们是随③段携带的供给件，改动只写 `stage-delivery` 自己的 `SKILL.md` / `references/`；默认档与可选档平行，不缝成一条流水线，也不把 `oil-ui-pro` 的评分循环当成本段 Gate 的替代） +- 猜 `<项目>`：定不出来还硬写，把产物落到别的项目目录下 +- 把 `DESIGN.md` 写到仓库根：多项目会互相覆盖 +- 段间停下来问「要不要继续」：全流程（自动处理）模式下直接进下一段，只在段末输出报告 +- 把两种模式混用：在自动处理模式下自作主张停下问方案，或在「方案确认」模式下确认前就开跑②③④ +- 在「方案确认」模式下把①段的方案当成已确认就往下跑：该模式下①段末必须停下等用户确认（含「不做什么」） +- 下游擅自裁剪上游已拍板项：②③④发现要砍①段或决策表里已拍板的东西时，不许自行裁掉或改口径，必须列成「与已定决策的差异」交用户显式确认 +- 把模式当成段：模式是「要不要在①段末停」的开关，不是第五个段，别为它单独造段或造产物 +- 跑了却不说：没声明当前段 / 子步与依据文件，或偏离了被调 skill 的主流程却不声明、不记偏离单（应为：开工先声明、每个子步再声明、偏离当场声明） +- 让③段顺手把说明区或产品文档写了（那是第④段 `stage-proto-doc` 的活） +- ④段里重新规划产品、重新设计界面，或写原型上没有的页面 / 功能 / 业务规则（④段只解释与记录**现有**原型） +- 问外部模型时堆砌背景：把过程留痕、废弃做法、内部约束清单整段贴进去（应按「征询外部模型（GPT）的提问口径」只给关键背景 ＋ 明确问题） +- 落盘文档开头不给图，或图与正文各说各的（应按「产出文档开头必须有图」先上图、再写正文，两处对得上） +- 过「说人话」时把「注入个性」那半也照做：加观点、加第一人称、写感官细节与比喻、允许跑题（应按内容准则只取「去 AI 味」那半，产出仍是客观书面说明文） + +## 改名 / 改供给后的自检 + +```bash +python scripts/check_naming.py --ws <工作区> +``` + +它查四段段名与子步名在「总入口 ↔ 各段 `SKILL.md` ↔ 各段 `references/`」之间有没有漂，包括 H1 与子步表是否一致、总入口子步列有没有漏项、runbook 必读表有没有引用已移除的资产、两份副本是否一致。纯静态比对，不需要渲染，不需要外部依赖。 + +为什么必须有它：实测当天漏过两次，当时没有任何门禁会报错。 + +第一次（2026-10-02）：改段名时 `SKILL.md` 改了，但 `references/stage-discovery/references/grill-me.md` 的 H1 仍写「需求澄清（grill-me · 调研段）」；`references/stage-requirements/SKILL.md` 子步表写「2b 功能流转」而正文 H2 写「## 2b 状态机」；总入口④段子步列只写「4a 说明区 / 演示引导」漏了 4b / 4c。三处都只能靠回读发现。 + +第二次（2026-10-06）：②段收窄为「只细化功能」（7 份产出变 1 份）后，各段 `SKILL.md` 都改了，但总入口的三处仍写着旧结构——四段表的②段子步列仍是「2a 功能定义与压测 / 2b 功能流转 / 2c 功能图示」，四段表的①段子步列「1c 产品定位与商业设计」未随段内改名（段内已改称「产品定位与场景」），正文仍写「①与②各跑一次 `grill-me`」并指向两份同名文档，实际全场只有①段一份。闸门当场报 6 个 FAIL，根因是「改了承载段、忘了总入口」。 + +由此立一条硬纪律，与「换供给不能只改承载段」同型：凡改子步结构 / 段内产出清单 / 段间交接口，必须连带改总入口 `product-planning/SKILL.md` 的「四段结构」表与「交接口」表，不改就是半改状态。 + +改了段名 / 子步名 / 判据供给源之后必须跑一次，并把结果记进当日 memory。改完不校验，下次读契约的人拿到的是错的配方。 + +本脚本只查文本一致性（H1 ↔ 子步表 ↔ 总入口 ↔ 副本），查不出「判据口径是否自相矛盾」。例如「②段到底该不该给页面结构」这种反转，闸门一个字都报不出来。口径类改动要靠人工回读，且必须把反转理由与用户原话写进文档留痕。 + +脚本输出里的 `[提示]` 项（旧名出现）不计入失败，但要人工看一眼是不是落在「废止理由块」里——落在里面是正当留痕，散落在正文里就是真残留。 + +2026-10-07 起本技能只在全局一份：技能根下的 `product-planning/`。它就是本体，不再有「主 / 副 / 装入」三副本，也不再需要「三处 md5 复核」（那只在有副本时才有意义）。改完只跑一次 `check_naming.py --ws <工作区>`。用户原话：「把产品规划复制到 workbuddy 全局skills中 后续维护和使用全局技能」。工作区原先那三份已归档到 `归档/技能迁全局-20261007/`（未直删，可随时取回）。 diff --git a/product-planning/references/_留痕/N6-20261016/_crlf-baseline.json b/product-planning/references/_留痕/N6-20261016/_crlf-baseline.json new file mode 100644 index 0000000..a17ed25 --- /dev/null +++ b/product-planning/references/_留痕/N6-20261016/_crlf-baseline.json @@ -0,0 +1,80 @@ +{ + "SKILL.md": { + "size": 37565, + "crlf": 0, + "lf": 305, + "md5": "b3187d397b604a27f56a1b0745a4749c" + }, + "references/stage-delivery/SKILL.md": { + "size": 50968, + "crlf": 0, + "lf": 384, + "md5": "b1f9b9232812e5b415fe91d438adbca9" + }, + "references/stage-delivery/references/execution-runbook.md": { + "size": 48323, + "crlf": 0, + "lf": 476, + "md5": "7a468aeb9339f550b6274f086d0c4727" + }, + "references/stage-delivery/scripts/_common.py": { + "size": 6629, + "crlf": 143, + "lf": 143, + "md5": "bc96fad261924902e0ee1aa1a0bdeca0" + }, + "references/stage-delivery/scripts/check_js.py": { + "size": 5379, + "crlf": 110, + "lf": 110, + "md5": "d4e9e195443a7331c4a8c700c12c6a9f" + }, + "references/stage-delivery/scripts/check_skeleton.py": { + "size": 6221, + "crlf": 139, + "lf": 139, + "md5": "9cac0006b9572e84c3b1fb92f55c3873" + }, + "references/stage-delivery/scripts/selftest_gates.py": { + "size": 8160, + "crlf": 152, + "lf": 152, + "md5": "9d7026c32378fbf9faadccc688608740" + }, + "references/stage-proto-doc/SKILL.md": { + "size": 13669, + "crlf": 0, + "lf": 181, + "md5": "f10e313002f08448a323f45031822078" + }, + "references/stage-proto-doc/references/doc-area-spec.md": { + "size": 5189, + "crlf": 0, + "lf": 72, + "md5": "e9ef3b58a82dcf3d0587a0a99356878d" + }, + "references/stage-proto-doc/references/doc-language-spec.md": { + "size": 11347, + "crlf": 0, + "lf": 322, + "md5": "769a49ea207ada3a18de96d7c6056517" + }, + "references/stage-proto-doc/assets/产品文档模板.html": { + "size": 15998, + "crlf": 0, + "lf": 247, + "md5": "21928bdf1139b20ebc59090bbe1a1af3" + }, + "references/stage-discovery/SKILL.md": { + "size": 21556, + "crlf": 0, + "lf": 228, + "md5": "4b48512d17f64b1295b62613658b6016" + }, + "references/stage-requirements/SKILL.md": { + "size": 17729, + "crlf": 0, + "lf": 172, + "md5": "50dc65798eb27778e136bf3040918d74" + } +} \ No newline at end of file diff --git a/product-planning/references/_留痕/N6-20261016/references/stage-delivery/SKILL.md b/product-planning/references/_留痕/N6-20261016/references/stage-delivery/SKILL.md new file mode 100644 index 0000000..8449576 --- /dev/null +++ b/product-planning/references/_留痕/N6-20261016/references/stage-delivery/SKILL.md @@ -0,0 +1,385 @@ +--- +name: stage-delivery +description: 产品规划第③段，界面交互。设计工程供给默认来自 oil-ui-pro（方法主线与独立评审）加本段自带样式库（定调与令牌），另有可选供给档（本段自带、可选择使用；供给关系见正文 §供给）：先落设计契约与令牌表（Gate-1 硬闸），再构建页面，再收口/动效/终检（Gate-2/3），中途加一轮 GPT 参考版。判据结构为「正向目标为主、禁令只留最关键三条」。当用户要做 UI 规范、设计系统、页面原型、交互动效、界面审查、视觉打磨，或说"只做界面交互"时调用。 +--- + +# ③ 界面交互 + +回答两个问题：长什么样、怎么操作。产出 `docs/pm/<项目>/DESIGN.md` 与 `docs/pm/<项目>/ui/*.html`。 + +> 段名为什么是「界面交互」（2026-10-02 定）： +> 删「交付」：①②③都产出落盘文件，「交付」是三段共有的属性，不是③的专属；④段也在交付（说明区与独立产品文档），留着会让人以为③管完就结束了。 +> 补「交互」：本段原先只讲「长什么样」，可 3b 原型硬要求每个按钮、每个跳转都真能走（`:236`），3c 的参考版对照也要逐项看空态 / 加载 / 错误 / 反馈（`:148`、`:150`）。交互判据一直在做，却没有名字，补上才与本段实际职责相符。 +> 与④段的界：③造物（界面与交互本身），④解释与记录（说明区与独立产品文档，只记现有原型、不重新设计）。 + +> `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。`DESIGN.md` 放项目目录，不放仓库根，避免多项目互相覆盖。 + +## 供给（唯一权威处 · 改供给只改这一块） + +> 🔴 ③段的供给关系**只在本块定义一次**。本文件其余章节、`references/execution-runbook.md`、`references/layouts-tooling.md`、以及总入口 `product-planning/SKILL.md`，提到供给时一律**引用本块的行名**（写成「见 §供给·定调与令牌」这样，行名就取下面那张表的左列），⛔ 不许再复述「谁是默认、路径在哪、装了才有」。 +> 改了供给 ⇒ 只改本块，然后跑 `scripts/check_naming.py`；发现别处有复述 ⇒ 删掉、改成引用。 +> ⚠️ 边界：本块管「有哪几档、谁默认、路径从哪个根起」。各档内部的具体篇目（如可选档工艺判据下的某一篇）属执行细节，留在 `references/execution-runbook.md` 各步里 —— 那些不算复述，改档不会牵动它们。 +> ⚠️ 为什么立这一块（2026-10-08 用户定）：此前这一个事实被复述约 40 处，改一次（默认主线由 `open-design` 换成 `oil-ui-pro`）动三份文件 17 处，仍然漏掉 13 处口径 —— 那是复述式写法必然的代价。单一可信源才拦得住漏改。 + +| 供给位 | 默认来源 | 可选来源 | 管什么 | 用在哪 | +|---|---|---|---|---| +| 方法主线 | `oil-ui-pro`（全局技能，按技能名引用） | 无 | 方向探索 → 建结构 → 取实证 → 独立评审打分 → 验证交付 | 全段；3a / 3d 最重 | +| 定调与令牌 | 自带样式库 `assets/design-systems/<选定一套>/`（随段携带，现 1 套 `design-system-tiaoyue`） | `assets/open-design/design-systems/<选定一套>/`（153 套） | 调性、全套令牌、组件形态。⚠️ **能力边界（2026-10-13 订正）**：自带样式库**不止调色板级** —— `design-system-tiaoyue/assets/component-library/`（采集于 2026-10-12）含 **9 个板块的整页快照**（`snapshot/<板块>.html`，去脚本、图片 URL 绝对化，7 个板块与线上逐像素一致率 ≥99.3%）、**345 个自有组件族**（`gallery.html` 是可视化总库，带搜索与一键复制 HTML）与**整站 CSS 原样合并**（`tiaoyue-all.css`，53 张 sheet ／ 1.11 MB）。⇒ **要整页骨架就直接改快照当原型页**：打开对应板块的 snapshot、改文案、删模块，立刻得到像素级同款的整页；要单个组件就走组件库的「复制 HTML ＋ 引一次 tiaoyue-all.css」。⛔ 仍不许把「供给在位」读成「不必核对」：快照只反映抓取时刻，JS 运行时状态（轮播帧、滚动位置、动态 class）还原不了，那部分要在 3d 里声明为无来源。（本节 2026-10-08 的原表述「只到调色板级…不含源站的界面骨架」写在 component-library 采集之前，已过期作废。） | 3a 的 D1 | +| 版式骨架 | `references/layouts-tooling.md`（工具型页面用） | `<技能根>/open-design/design-templates/web-prototype/`（营销页向；工具型⛔ 不许套） | 工具型九档的名单与判读见 `references/layouts-tooling.md` §0（⛔ 本块不复述名单；2026-10-08 追加「导航栏」一档 = §4.9） | 3b | +| 工艺数值判据 | `references/execution-runbook.md` §3.4 ＋ `references/layouts-tooling.md` §5.5 | `<技能根>/open-design/craft/`（13 份） | 字阶 / 配色 / 状态齐备 / 动效纪律 / 反 AI 味 / 无障碍。⚠️ **未选可选档时，后四项（反 AI 味 / 无障碍 / 动效纪律 / 表单校验）没有供给来源** ⇒ 必须在 `3d-审查报告.md` 里逐项显式记为**本段证据缺口**（写「无供给来源，本项未判」），⛔ 不许默不作声地跳过、也⛔ 不许拿别的判据冒充它过了 | 3a 判据、3d 终检 | +| 独立评审协议 | `oil-ui-pro` 的 `references/visual-review.md` ＋ `references/tools.md` | 无 | 没看过制作过程的评审打分 ＋ 截图取证 | 3d | +| 多方向比选 | `oil-ui-pro` 的 `references/design-direction.md` ＋ `references/style-explorer.md` | 无 | 方向卡与风格对比页 | 3a 按需 | + +> 🔴 供给是**分层**的（2026-10-08 用户定案）：`oil-ui-pro` 是**基础层** —— 视觉与体验的底线判据都出自它；其余各档（定调与令牌 / 版式骨架 / 工艺数值判据 / 本段自有的 `execution-runbook.md` 与 `layouts-tooling.md`）都是**叠加层**：可以在它之上叠加更多设计规范，只许**更严、更具体**，⛔ 不许**放宽或推翻**基础层。叠加层与基础层冲突 ⇒ **以基础层为准**。 + +> ⭐ 可选来源只有一处：`open-design` —— **同根技能**（装在技能根下）（源 `nexu-io/open-design@0.23.1`，Apache-2.0；署名与裁剪说明见 `<技能根>/open-design/ATTRIBUTION.md`，装在 `<技能根>/open-design/`）。它是**独立技能、可选择使用**：选了才用，不选不影响本段开工。 + +`open-design`（上面那张表的可选来源）给三处，都在 `<技能根>/open-design/` 下： + +1、`design-systems/<选定一套>/`：`DESIGN.md` 定调性 ＋ `tokens.css` 给全套数值（圆角与阴影在这里）＋ `components.html` 给组件形态。 + +2、`craft/`：字号刻度 / 配色配额 / 状态齐备 / 动效纪律 / 反 AI 味 / 无障碍。 + +3、`design-templates/web-prototype/`：种子 `assets/template.html` ＋ 8 个版式骨架 ＋ 自查清单。 + +⭐ 选了自带的 `design-system-tiaoyue` 时怎么读（⚠️ 套内命名与 `open-design` 不同形，别按 `DESIGN.md` 去找）： + +| 要什么 | 套内路径 | +|---|---| +| 入口（规范总纲、生成时的参考范围） | `assets/design-systems/design-system-tiaoyue/SKILL.md` | +| 令牌（含暗色一套） | 同目录 `assets/tokens.css` ＋ `assets/tokens-dark.css`（色值原始记录 `assets/brand.json`） | +| 组件形态 | 同目录 `references/components.md` ＋ `references/design-system.html`（组件族清单 `references/library.json`） | +| 已知冲突 / 取舍记录 | 同目录 `references/known-conflicts.md` ＋ `references/capture-notes.md` | + +> ⚠️ 路径怎么找，按两类分开写：本段**自带件**（`design-capture/`、`design-systems/`）写**段内相对路径**（`assets/design-systems/...`）；**同根技能**写 `<技能根>/<技能名>/`（`open-design` 用 `<技能根>/open-design/...`，`oil-ui-pro` 按技能名引用），与物理位置无关。⛔ 不按绝对路径爬、⛔ 不写死 `../` 层数（位置一变就失效且不报错）。 +> 🔴 定调来源唯一：每次设计只选一套，默认与可选**不混用**（混用 = 没有调性）。套名与选择理由写进 `DESIGN.md`。 +> ⛔ 判据正文仍只在本段（`references/execution-runbook.md` 与 `references/layouts-tooling.md`）。⚠️ 供给是分层的，分层定义见 §供给：`oil-ui-pro` 是**基础层**，本段自有判据是**叠加层**；同一条判据两处都有且口径不同时，⛔ 本段不许放宽基础层，只许更严、更具体，并在 runbook §3.4 标注「本项目追加」。 +> ⛔ 不许把 `oil-ui-pro` 的评分循环当成 D 阶段的替代：它是评审方法，Gate-1/2/3 该过还得过。 +> ⛔ 不动用可选来源时，⛔ 不许凭感觉编一套顶上（那正是本项目反复踩的坑）；craft 独有的那几项（反 AI 味 / 无障碍 / 表单校验 / 动效纪律）明说「本次无供给来源」。 +> ⚠️ `oil-ui-pro` 自带联网版本检查与自动更新（每次使用会连 `ui.oiloil.org`，发现新版用 `npx` 覆盖自身目录）。这是本项目收录时用户明确要求全量搬入的例外项，与「依赖外部服务一律不收」的既有纪律冲突，记录在案，不扩散到其他技能。想关掉设环境变量 `OIL_NO_UPDATE_CHECK=1`。 +> 供给件都不依赖付费云 / MCP / API Key 才能用于设计：`open-design` 去掉那些之后剩下的全是静态 md / css / html（其 daemon、云模型服务、`packages/components` 的 tsx 未收录）；`oil-ui-pro` 的设计方法宿主中立、离线可用（联网仅用于版本检查）。 +> 冲突处以 §供给·方法主线（基础层）为准；本段自有判据与 `DESIGN.md` 是叠加层，只许更严，⛔ 不许与基础层相反。供给件的价值在给正向目标、给方法。 + +> 为什么换掉原来的主干（2026-10-02 用户定案）：原主干 `ui-page-design` 已从磁盘移除，③段只剩规则壳，壳里又全是减法型判据，机检能判「不违规」却判不出「好看」，18 轮回改把页面越推越白。换供给的同时必须换判据结构：正向目标为主，禁令只留最关键的。 + +> ⭐⭐ 本段在②段给定的骨架里做视觉与交互（2026-10-06 用户定案）。 +> +> 口径：②段钉骨架，③段做皮肉。 +> +> 🔴 「②段管什么、本段管什么」的完整清单（含两侧逐行对照）只在②段 `references/stage-requirements/SKILL.md` +> 的 §②—③ 交接口 定义一次 —— ⛔ 本文件不复述那张表，免得两处漂。用户原话也放在那一节，此处不再抄。 +> +> 🔴 旧口径站不住的地方：它把「有哪几页」留在本段，于是本段做一版一个样，②段手里没有任何东西能判断本段改得对不对。 +> ⭐ 本段拿到的骨架是冻结的：⛔ 不许新增 / 移动 / 删除板块。缺板块要回②段改②段（见「硬约束」的对应禁令）。 +> +> 仍在本段手里的两个字段（它们在给定骨架之内决定怎么摆得好看）： +> - `必要内容`（减法）：⚠️ 口径已调整。它不再决定哪些内容上屏（那是②段分档表的活），而是核对②段给的信息是否都在骨架里有落点；⛔ 本段不得以它为由增删信息档位。 +> - `结构骨架`（加法）：⚠️ 口径已调整。它不再独立决定几个区块，而是把②段给的板块清单翻译成具体的骨架档 / 列宽 / 密度目标（骨架档选哪个、密度多少，仍是本段的活）。 +> +> ⛔ 本段不许回头改②段的骨架（那是②段）；⛔ 也不许无视②段骨架自己另起一套。判据：D0 里的页面清单与每页板块，必须与②段《界面布局》逐条对得上；对不上就停下来问②段要哪一版。 + +顺序 3a → 3b → 3c → 3d。先有规范再出原型，不许反过来；原型能点通后先取一份外部参考版，再收口打磨。 + +> 照 `references/execution-runbook.md` 逐步走。那是本段的固化执行手册：按 D 阶段排的必读表、每步验收判据、脚本跑法、偏离单格式、完成标准清单都在里面。本文件写规则，手册写顺序与验收。 +> 开工前先声明、每进一个子步再声明、偏离当场声明（三字段：当前子步 / 依据文件 + 小节号 / 产出落点）。这条不可商量。 + +## 子步与产物 + +| ③段子步 | 做什么 | 产物 | 闸 | +|---|---|---|---| +| 3a 视觉规范 | 定契约（减法 + 加法）→ 定调（选定设计系统）→ 落令牌表〔方法主线按 `oil-ui-pro` 的方向探索走；要拉开方向让用户挑时用它的对比页〕 | 设计契约 + 令牌表 → `DESIGN.md` | Gate-1 方向门 | +| 3b 原型 | 按模板种子 + 版式骨架构建 | `docs/pm/<项目>/ui/<原型>.html` | — | +| 3c GPT 参考版 | 让 GPT 按需求＋风格**独立生成一版当参照物**（本段特有，两个设计技能都不覆盖） | `3c-GPT参考版.md` | — | +| 3d 审查与打磨 | 收口 → 动效 → 终检〔按 `oil-ui-pro` 的评审协议做一轮独立评审打分〕 | file:line 清单 + `3d-审查报告.md` | Gate-2 / Gate-3 | + +挡位开工前定一次，默认标准：纯原型可降快速（定契约 → 定调 → 构建 → 终检）；常规页面走标准（全跑）；对外页面走严格（三闸全开 + 中间产物落盘）。 +`Gate-1` 与 `Gate-3` 是硬闸，任何挡位都不可跳，哪怕只做原型，也要打开看一眼。 + +## 三条铁律（只留不可省略的） + +| # | 铁律 | 违反后果 | +|---|---|---| +| 1 | 先定死，再写码。未产出设计契约与令牌表前，禁止写任何组件代码；禁止边写边调样式。 | 返工、风格漂移 | +| 2 | 状态穷举。`loading / empty / error / success / disabled / 无权限` 逐项给结论（判据见 §供给·工艺数值判据）。 | 上线即翻车（最高频漏项） | +| 3 | 不渲染不算完。交付前必须在真实环境渲染一次并肉眼确认。 | 裁切/重叠/失效控件逃过检查 | + +> 禁令就这三条，其余一律去 §供给·工艺数值判据 里查（默认档按本段两份的对应章节；可选档按其工艺篇目，逐篇见 §供给·工艺数值判据）。 +> ⛔ 不在本文件里抄写禁令清单。抄了就变两份，两份必然漂；更要紧的是，抄禁令会把正向目标挤出视野，这正是改版前③段只剩「不要什么」、页面越改越白的根因。 +> 一条例外（本项目特有，供给件里没有）：结构性容器靠底色差 + 阴影分层，不挂围合边框（来源：本项目 E-62 / E-63 实测）。当选定设计系统写「卡片描边」时，以本条为准。 +> 限载：同一时刻只读 1~2 份供给原文，用完释放。这条不再单列铁律，但仍是硬约束（可选档定调候选与工艺判据份数都不小，全读必然互相稀释）。 + +## 必读（限载：一次只读 1~2 份，用完释放） + +| 环节 | 取哪些供给位（定义见 §供给） | +|---|---| +| 3a 方法主线 | §供给·方法主线 | +| 3a 定调 | §供给·定调与令牌（默认档；要用可选档就在 `DESIGN.md` 写明理由）。入口 / 令牌 / 组件形态按 §供给 里的「套内怎么读」取 | +| 3a 判据 | §供给·工艺数值判据（本项目追加条在 `references/execution-runbook.md` §3.4） | +| 3a 多方向比选（按需） | §供给·多方向比选 | +| 3b 构建 | §供给·版式骨架 ＋ §供给·工艺数值判据（工具型只取默认档） | +| 3d 独立评审 | §供给·独立评审协议 | +| 3d 终检 | §供给·工艺数值判据 ＋ §供给·版式骨架 | + +> ⚠️ 3b 只取 §供给·版式骨架 的默认档。可选档那套（`web-prototype`）是营销落地页向，只在判「要不要套它的流程」时读。 +> ⚠️ 本表只写「哪一步取哪个供给位」，⛔ 不写路径、不写默认判断 —— 那些只在 §供给 定义一次。 +> 本段 `references/` 只放流程规则，⛔ 不放风格；随段携带的样式风格一律放 `assets/design-systems/<套>/`（🔴 2026-10-07 用户令两条：「把 `design-system-tiaoyue` 整合到 `product-planning` 作为一种样式风格」＋「后续可以添加多种风格，每次只能选择一种进行设计」⇒ 只把「不放风格」这条放宽到 `assets/`，`references/` 仍不放）。 +> ⚠️ 续加新风格时的硬要求：目录名与可选档同形（`assets/design-systems/<套名>/`），套内自带入口文件（`SKILL.md` 或 `DESIGN.md`）；⛔ 不许改已入套的文件内容，原样搬入、只在本文件登记去向。 +> 🔴 定调来源唯一（两档见 §供给·定调与令牌）：每次设计只选一套，⛔ 不许混用两档（混用 = 没有调性）。套名与选择理由写进 `DESIGN.md`。 +> 既有项目中凡引用旧风格来源（`minimalist-ui` / 皮肤族 / `ui-ux-pro-max` 检索结果）的 `DESIGN.md` 行，重跑 3a 时一律改写为选定套 + 留痕对照。 + +## 3a 视觉规范（定契约 + 定调 + Gate-1） + +第 0 步 · 供给核对（每轮必做，防漂移）：按 §供给 逐档核对在位 —— 默认档必核，可选档**选了才核**（其可选来源那三处，见 §供给 表）。核完把选定套名与 `DESIGN.md` 里记录的上次套名比对。 + +- 一致 → 直接定契约。 +- 不一致或供给缺失 → 先停下报告，⛔ 不许拿别的套顶上，也不许凭记忆写风格。把差异列成「供给变更清单」，在会话里向用户呈现并确认后，再改 `DESIGN.md`，把新套名与清单写进修订记录。 +- 本步存在的理由：`DESIGN.md` 是上一次供给状态下产出的。供给换了却没核对，就会长期拿着旧调性当准绳。 + +D0 锚需求：按 `references/execution-runbook.md` §2.1 的契约模板产出设计契约（十二个字段）。字段清单与逐条判据以 §2.1 为准 —— ⛔ 本文件不重复列，免得两处漂。 + +> ⭐⭐ 第十二字段「交互清单」是 2026-10-02 新增，段名改名的直接后果（段名从「界面与交付」改成「界面交互」，但「交互」在流程里此前没有落点：可点通在 3b、查反馈在 3c、动效在 3d，三处各判一部分，谁也不负责整体）。 +> 它写什么：逐个可点元素一行，四列——元素（哪个）｜触发（点了/输了/滚到哪，发生什么）｜反馈（状态怎么变、给什么提示、多久消失）｜何时不可点（哪些条件下 `:disabled`，条件是什么）。 +> 它不写：动效参数（归 3d 按 §供给·工艺数值判据）、视觉样式（归令牌表）、状态六项的有无判定（归下一字段 `状态覆盖`，本字段只写「这个元素可点时点了会怎样」）。 +> 为什么是契约字段而不是新子步：交互一旦单独成文，就会与 `必要内容`、`状态覆盖` 三处互相矛盾——这正是记忆里「同一事实多处落点必然打架」的病。收进契约 = 一个字段、一处裁决、一个门禁。 +> 判定「漏没漏」：页面里每一个能点的东西都必须在这张表里出现。表里没有 ⇒ 它不该可点（改成静态文本，或回 D0 补进 `必要内容` 再点）。 + +D1 定调：从 §供给·定调与令牌 的默认档里选一套；要用可选档就从可选档里选（⛔ 每次只选一套，两档不混用），不凭感觉编，也不全读： + +- 怎么选：按本项目的页面类型挑。读候选套 `DESIGN.md` 的第 1 章 `Visual Theme & Atmosphere`，认准写明该类的那一句（工具型数据密集界面 ⇒ 认 `data-dense, enterprise` 这类描述）。可选档的候选分两代模板（A 组 / B 组章节名不同），按自己那套的章节读，不必统一。 +- ⚠️ 选了自带库那套（`design-system-tiaoyue`）时：套内没有 `DESIGN.md` ⇒ 读它自己的 `SKILL.md`（规范总纲 ＋ 生成时的参考范围）＋ `references/known-conflicts.md`（已知取舍）；入口 / 令牌 / 组件形态按 §供给 里那张「套内怎么读」表取，⛔ 别按可选档那套的三件套去找。 +- 选定后读三件：`DESIGN.md`（调性 + 色值 + 字号刻度 + 间距刻度 + 动效基调）→ `tokens.css`（圆角与阴影只有这里）→ `components.html`（组件实际长相）。 +- 要换风格 ⇒ 下一轮重跑 D1 重选一套，旧套留痕（用户 2026-10-07：「后续可以添加多种风格，每次只能选择一种进行设计」）。 +- 没找到匹配的套 ⇒ 换一个类型词再挑一次；仍不行就直说「未找到匹配」，不许拿泛化结果当结论落盘。 +- ⚠️ 工具型页面的版式不在可选档的模板里（可选档是营销页向；骨架名单与理由见 `references/layouts-tooling.md` 开头）。工具型页面的版式由 D0 的 `结构骨架` 字段决定，不从模板抄。 + +- 产出令牌表：色值 / 字体（标题字体是关键项）/ 间距两档（主刻度 `4/8/16/24/32/64` 供布局 + 控件层微网格 `2/4/6/8/12` 仅供按钮内衬、徽章内衬、图标间隙、开关与进度轨微几何）/ 圆角 / 字阶定值表（七档各一个 px，不是区间）/ 高度层级（每层都有多层叠层值）/ 布局脚手架（骨架档落到具体列宽 + 窄屏变化）/ 组件规格（按钮三档 + 卡片两档 + 输入框 + 徽章的具体高度与内衬；实底底色 ≥2 种）/ 动效基调——全部为具体值，禁止「待定」，每档只许一个定值 + +落盘 `docs/pm/<项目>/DESIGN.md`：令牌表内容并入本项目既有的三层 token 结构（primitive → semantic → component；组件只引语义层、语义层只引 primitive），设计契约作首节。`DESIGN.md` 是原型的绑定规范，原型只许引它的 token。 + +Gate-1 方向门（硬闸，不可跳）——按本表逐项自检（字段定义与填写位见 `references/execution-runbook.md` §2.1；⛔ 供给件没这一项，十二字段只能在此判）： + +| 检查项 | 通过条件 | +|---|---| +| 设计契约 | 十二个字段全部填写，无一为空或「待定」；有重复项时重复项的信息量已逐条列出次级信息 | +| 页型判定（2026-10-05 新增） | 已写出「营销页还是工具型页面」+ 依据；工具型页面的 D0 里零 `.eyebrow` / 零 `.lead` / 零 `.hero` | +| 结构骨架（加法面） | 骨架档 / 区块划分 / 密度目标三者已写；区块 ≥2 个且每个有文字标题；`必要内容` 每条都有归属区块 | +| 交互清单（加法面，2026-10-02 新增） | 页面上每一个可点元素都在表里（元素 / 触发 / 反馈 / 何时不可点 四列齐全）；表里没有的可点元素为 0 | +| 状态覆盖 | 六个状态逐项有结论（勾选，或「不适用 + 理由」） | +| 令牌表 | 色值 / 字体 / 间距两档且适用面已分开写 / 圆角 / 阴影全为具体值 | +| 字阶定值表 | 七档每档一个 px 定值（不是区间）；相邻档差 ≥2px；每档只许一个定值 | +| 高度层级 | 每层都有多层叠层值；同层级同值 | +| 布局脚手架 | 骨架档已落到具体列宽；窄屏变化写具体 | +| 组件规格 | 按钮三档 + 卡片两档 + 输入框 + 徽章均为具体值；同一父区块内主档 ≤1；实底底色 ≥2 种 | +| 供给核对（本项目附加） | 按 §供给 逐档核对在位（默认档必核，可选档选了才核）；选定套名与 `DESIGN.md` 记录一致；不一致则变更清单已确认并写入修订记录 | +| 反 slop | 无紫→粉渐变、标题未用禁用字体、强调色已写明允许位置 | +| 拒绝清单 | ≥3 条，且每条可判定 | +| token 引用完整性（本项目附加） | 语义层只引 primitive、组件层只引语义层、无孤立 token | + +任一项不过 → 停在 3a 补齐，不进 3b。 + +> 对比度门槛见 §供给·工艺数值判据 里配色那一份（数值登记在 `references/execution-runbook.md` §3.4 的数值判据段），由终检阶段按真实像素复测（静态算不准 CSS 变量叠加后的结果）。 +> 已知环境问题：`npx @google/design.md lint` 在本机完全不可用（alpha + clack 交互库，非 TTY 管道下静默且 exit 0）。不要拿它当校验关卡，也不要因它无输出就认为通过。 + +## 3b 原型（构建） + +> ⛔ 开工前先判页型（2026-10-05 新增，硬前置）：写下「本页是营销页还是工具型页面，依据是什么」。 +> 两种页型的目的不同，骨架不能通用：营销页目的是说服（主张 → 论据 → CTA），工具型页面目的是完成一件工作（数据 + 操作）。 +> 判别口径：要用户「下决心去做某事」⇒ 营销页；要用户「把这件事做完」⇒ 工具型页面。⚠️ 判不准时按工具型处理（默认取严）。 +> 判不出来不许进 3b，停下来回改 D0 的 `结构骨架`。 +> 🔴 为什么这条是硬前置：§供给·版式骨架 可选档那套的种子 `assets/template.html` 是营销落地页骨架，自带 `.eyebrow`（眉标）与 `.lead`（副标题）。不判页型就照种子做，会得到「标题上方一行小字 + 大标题 + 下方一行灰色小字」的三段式——那是 2026-10-05 用户实测指出「像实习生画的」的唯一根因，而且结构判据全绿（判据判类名合法性，判不出「这不是工具界面的排版」）。页型不判，后面换什么设计系统都救不回来。 + +要选可选档时，可按它那份 `SKILL.md`（§供给·版式骨架 的可选档）的六步走：读种子 → 把 `assets/template.html` 复制成 `index.html` 并替换 `:root` 令牌 → 先定版式节奏再粘骨架 → 填充 → 自查 P0/P1/P2 → 落盘。不选它就按默认档（`references/layouts-tooling.md`）的骨架与落地自检走。两条路线都要求「先选定一个明确的美学方向再写码」，与铁律 1 同向。 + +- ⭐ 工具型页面先判形态，再挑骨架（2026-10-02 新增）：读 §供给·版式骨架 的默认档。本项目是工具型数据密集界面，可选档那套是营销页向、与本项目不匹配（名单与理由见 `references/layouts-tooling.md` 开头）。 + ⚠️ 两份工具型文件的分工（2026-10-05 补）：本技能 `references/layouts-tooling.md` 给可粘贴 HTML 骨架 + 逐条判据正文（§5.5），是默认档；选了可选档时，它那份 `tooling.md` 另给四形态判定句 + 通用红线纲要，只作指路。⛔ 判据只在 `layouts-tooling.md` 展开，`tooling.md` 只指路，两处展开必然漂。 + 形态判定一句话：页面上能数出「并列的同类记录」⇒ 列表型（工具型默认首选）；数不出、页面围绕单个对象展开 ⇒ 详情型；主操作要在两个工作面之间来回 ⇒ 侧区型。 + ⛔ 不许拿营销页骨架顶替工具型，那是「没做形态判定」的默认行为，等于退回 18 轮前的病根。判不出形态就去改 D0 的 `结构骨架` 字段，⛔ 不许随手挑一个。 +- 不许从零手写 `
`：先挑最接近的骨架粘进去再改。用了可选档时，可选档那套的 `layouts.md` 开头的类清单（`section` / `container` / `card` / `btn-primary` / `grid-3` …）必须在种子 `template.html` 的 ` + + +
+ +

<产品名> · 产品文档

+ +

+ 用法：把带 <尖括号> 的占位全部换成真实内容，删掉本节上面的示例行， + 再按第④段要求逐节填。编号口径：页面 P001…／使用场景 S001…／功能 F001…／二级功能 J001…，各自全篇唯一、按展示顺序通排。 +

+ +

一、页面结构

+

先给一张结构图，再列功能。页面框里按**功能区**分块，每个功能区画成自己的板块盒；连线只画真实存在的跳转，并在标签上写清触发动作。

+ + + + + + + + + + + + 入口：<从哪个页面> → <点什么> → <进到哪> + + <页面 A> + <一级页面> + + + <功能区名> + F001 <功能名> + F002 <功能名> + + + <页面 B> + <二级页面> + + + <功能区名> + F003 <功能名> + F004 <功能名> + + + <页面 C> + <独立页面> + + + <功能区名> + F005 <功能名> + + <触发动作> + + + <退回动作> + <触发动作> + + + + +

二、功能清单

+ +

页面功能

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
序号页面名称层级功能区功能功能做什么租户待开发
P001<页面 A><一级页面><功能区名>F001 <功能名><一句话说清它做什么、有什么限制>全部租户✓
<功能区名>F002 <重点功能名><重点功能用红字标出>麦芽租户✓
P002<页面 B><二级页面><功能区名>F003 <功能名><一句话说清它做什么>全部租户✓
<功能区名><待确认><待确认>全部租户✓
+

页面上每一项都要有 F00x 编号；页面序号／页面名称／层级合并格，功能区按区合并格；暂时没登记到功能的板块照样占一行，两格写「待确认」。

+ +

<二级功能名>（二级功能）

+

技能、模板这类**选项值**属于二级功能：它们由页面功能 <F00x 功能名> 承载，在这里**引用**那个页面功能，自己不再占 F 编号。

+ + + + + + +
序号二级功能项产出什么对应页面功能
J001<选项一><产出什么><F00x 功能名>
J002<选项二><产出什么><F00x 功能名>
+ +

重点说明

+ + + + + + +
重点项说明相关编号
<重点项一><为什么是重点、它覆盖哪些能力><F00x、F00x>
<重点项二><为什么是重点><F00x>
+

上述功能为本次新增功能。

+ +

三、使用场景

+ + + + + + + + + + + + + +
序号场景含几条流程优先级待开发对应功能
S001<用户要办成的一件事><N> 条P0✓<功能名（F00x）>、<功能名（F00x）>
S002<用户要办成的另一件事><N> 条P0✓<功能名（F00x）>
+

共 <N> 条使用场景，含 <N> 条流程、<N> 个操作步骤。

+

判定口径：用户通过产品功能办成、且**拿到一个结果**的才叫一件事；起手、分支、异常、同一件事的两种手法都并回所属那件事。拿不到结果的（进到某个页面、确定某个取值）不列为场景，只作功能步骤。

+ +

四、操作流程

+

每条流程画成一张**横向**流程图：步骤盒自左向右排、箭头横向连接；每个盒自带标题栏（只放步骤名），正文写页面／功能／操作／完成判据；**「操作」那行用强调色**。

+ +
+

S001　<场景名>

+

<这条场景是在什么前提下、办成什么事>

+ +
流程 1　<流程名>
+ + + + + + + + + + 1. <步骤名> + 页面：<页面名> + 功能：<F00x 功能名> + 操作：<这一步怎么操作> + <操作的续行> + 完成判据：<界面停在哪个状态> + + + + 2. <步骤名> + 页面：<页面名> + 功能：<F00x 功能名> + 操作：<这一步怎么操作> + 完成判据：<界面停在哪个状态> + + + + 3. <步骤名> + 页面：<页面名> + 功能：<F00x 功能名> + 操作：<这一步怎么操作> + 完成判据：<本件事最后一步> + + + + + + +
流程 2　<另一条流程（异常／等待等）>
+

同一件事下的分支、加载中、失败，都作为这条场景的**另一条流程**，不另起一节。

+
+ +

五、跨页与界面状态

+

跨页：<页面 A> → <页面 B>，<触发动作>；<页面 B> → <页面 A>，<退回动作>；<单向跳转与打开方式>。

+

界面状态（原型 ?state=）：

+
    +
  • ?state=<状态一> —— <状态说明>
    • +
  • ?state=<状态二> —— <状态说明>
    • +
+

状态名一律以原型为准；只写真正的界面状态，⛔ 不把页面层级当状态写。

+ +

六、待确认事项与偏离单

+
    +
  • <待确认一：谁在什么时间前定>
    • +
  • <待确认二>
    • +
  • 术语一致性：<是否对齐、与哪份文档对齐>
    • +
+ +
+ + diff --git a/product-planning/references/_留痕/N6-20261016/references/stage-proto-doc/references/doc-area-spec.md b/product-planning/references/_留痕/N6-20261016/references/stage-proto-doc/references/doc-area-spec.md new file mode 100644 index 0000000..4b86edf --- /dev/null +++ b/product-planning/references/_留痕/N6-20261016/references/stage-proto-doc/references/doc-area-spec.md @@ -0,0 +1,72 @@ +# 原型说明区规范 + +> 本文件是 `stage-proto-doc` 的方法论文档，由模型按需加载，没有斜杠命令。 +> 骨架与 `assets/产品文档模板.html` 同构 —— 说明区就是独立产品文档的六节，嵌进原型对应位置。两份产物共用同一套编号、场景、流程与功能定义。 + +## 定位 + +说明区是原型自带的注解层，不是产品功能。它不回答"长什么样"，回答的是： + +> 站在这个界面上，我这一步在干什么、我能输入什么、什么情况下它不给好脸色。 + +所以它贴在原型对应位置的下方，随当前所在的页面一起变。抽出来单独写一份，读者就得自己脑补对应关系。 + +## 六节怎么落进原型 + +- **一、页面结构**：页面结构图放原型首页顶部，图上标出各页面与其下的功能编号（页面 `P00x`／功能 `F00x`）。 +- **二、功能清单**：表格贴在对应功能区下方 —— 列：编号／页面／层级／功能区／功能（`F00x` ＋ 名称）／功能做什么／租户／待开发；二级功能另起一张表（`J00x`／二级功能项／产出什么／对应页面功能）。重点功能在功能名、说明、租户三处同时标红。 +- **三、使用场景**：每个场景一段，带前提／目标／原型位置（写到「页面 → 模块 → 控件或状态」，能在原型上点到）。 +- **四、操作流程**：每个场景一条横向流程图，规则见下节。 +- **五、跨页与界面状态**：写跨页跳转与数据传递，以及各界面状态（空／加载／失败／禁用等）怎么触发、呈现什么。 +- **六、待确认事项与偏离单**：待确认带三字段（复核人／复核时机／结论落点），偏离写清偏离了什么／原因／影响面。 + +## 场景怎么写 + +- 粒度是"人要完成的一件事"，不是一个按钮。"提交驳回"不算场景，"驳回一条片段并完成失败模式归类"才算。 +- 一个页面下的场景数控制在 2–4 个。1 个说明不了分支，5 个以上就该拆页面或拆功能区。 +- 顺序按发生频率排，不按界面从上到下排。 +- 前提一句话写清。例："预审排队、执行中或失败时人工仍可决策，但必须清楚自己在无依据的情况下决策。" + +## 横向流程图 + +| 规则 | 说明 | +|---|---| +| 形态 | 横向 `ol`，每项 = 序号圆点 + 步骤名，项间一个 `→` 箭头 | +| 每步内容 | 写清 页面／功能／操作／完成判据，「操作」行用强调色 | +| 溢出 | 横向滚动，不换行 —— 换行会读成两条并行流程 | +| 步数 | 2–6 步：超过 6 步说明这个场景该拆，1 步说明它还不算流程 | +| 交互 | 点步骤 → 下方出这一步的四项说明；再点收起；同级只选中一个 | +| 键盘 | 步骤是 `button`；`aria-current` 标当前项；说明区 `role="region"` 带 `aria-controls` | +| 箭头 | `aria-hidden`，它只是视觉连接符，不进朗读 | + +## 每项功能的四项要求 + +| 项 | 回答的问题 | 合格判据 | 不合格示例 | +|---|---|---|---| +| 做什么 | 这一步做什么、给谁看、落笔后产生什么 | 换一个组件这句话就不成立 | "展示相关信息，提升审核效率" | +| 入口在哪 | 可定位的页面与控件 | 能在原型上点到 | "相关入口" | +| 输入边界 | 取值域 / 上限 / 前置条件 / 必填与选填 | 说得出"什么不被接受"或"最多几条" | "支持筛选" | +| 异常与恢复 | 失败 / 空 / 禁用 / 重复提交 / 恢复路径 / 文案红线 | 至少一种"坏了怎么办"，且给出出路 | "暂不支持" | + +写输入边界，常见切入点：数量上限、字数或时长范围、哪些状态才可用、必填项有哪些、一次作用于一条还是全部。 + +写异常与恢复，常见切入点：加载中能不能点、失败了怎么重试、重复提交怎么挡、空的时候显示什么、禁用要不要给原因、文案不能写成什么。 + +### 文案红线 + +- 不得把自动结论表述为人工认可。机器判定只能说"进入队列 / 待人工逐条查看"，不写成"通过 / 已认可 / 已确认"。 +- 不用无法区分成因的笼统文案。"暂无数据"要拆成"批次为空"与"筛选无结果"两条出路。 +- 不承诺原型里点不出来的能力。说明区每条都要能在原型上指到对应元素。 +- 异常态必须给恢复路径。只写"失败了"不算说明，要写清楚下一步按哪里。 + +## 自查（逐条打勾） + +- [ ] 六节都落到原型对应位置，顺序与模板一致 +- [ ] 页面 `P`／场景 `S`／功能 `F`／二级功能 `J` 各自唯一且按展示顺序通排 +- [ ] 每个场景 2–6 步，每步写清页面／功能／操作／完成判据 +- [ ] 每项功能的四项都填了，且各自能通过上面的合格判据 +- [ ] 重点功能在功能名、说明、租户三处同时标红 +- [ ] 全文没有"通过 / 已认可"这类把机器结论说成人审的词 +- [ ] 每个禁用态都给了原因，每个异常态都给了恢复路径 +- [ ] 说明区文案与②段术语逐词一致 +- [ ] 点不出结果的场景已标 `funcOnly`，并在第六节写明为什么点不出来 diff --git a/product-planning/references/_留痕/N6-20261016/references/stage-proto-doc/references/doc-language-spec.md b/product-planning/references/_留痕/N6-20261016/references/stage-proto-doc/references/doc-language-spec.md new file mode 100644 index 0000000..78b15ee --- /dev/null +++ b/product-planning/references/_留痕/N6-20261016/references/stage-proto-doc/references/doc-language-spec.md @@ -0,0 +1,322 @@ +# 产品文档语言规范 + +> 来源：ChatGPT 网页版（2026-10-14，会话 `6acf7fc1-8d10-83e8-b328-8e885f5efb8c`）。 +> 用法：写④段的两份产物时逐句过一遍；第五节自检清单任一项不通过就改。 +> 它管**语言**；文档骨架（六节：页面结构／功能清单／使用场景／操作流程／跨页与界面状态／待确认与偏离）见上一级 `SKILL.md`。 + +--- + +## 一、语体与句式 +### 1.1 语体要求 + +使用客观、正式、书面的说明文语体。 + +面向产品、开发、设计人员，确保读者不查看原型也能理解文档内容。 + +描述系统行为时使用可验证的事实，不使用主观评价或个人感受。 + +区分已实现行为、计划行为、未实现行为和待确认事项。 + +不使用聊天式表达、营销式表达、口号式表达或未经证实的效果承诺。 + +### 1.2 句式要求 + +一句话只表达一个主要意思。 + +一个句子只描述一个主要动作、判断、规则或结果。 + +存在多个独立动作时，拆分为多个句子，并按执行顺序排列。 + +存在条件关系时，明确写出条件和对应结果。 + +存在因果关系时，明确写出原因和结果，不使用含糊的连接词。 + +描述操作时，优先使用「操作主体＋动作＋对象＋结果」句式。 + +描述规则时，优先使用「适用条件＋处理规则＋预期结果」句式。 + +描述异常时，明确异常条件、系统反馈和恢复方式。 + +删除不影响事实含义的铺垫、重复解释和语气修饰。 + +不得为了追求简短而省略执行主体、操作对象、条件或结果。 + +### 1.3 句子验收标准 + +一个句子包含两个及以上可独立执行的动作时，拆句。 + +一个句子包含两个及以上独立判断条件时，按规则复杂度拆分或使用列表。 + +句子出现代词时，必须能够从当前句或明确的上下文唯一确定指代对象。 + +句子出现条件时，必须能够判断条件成立与不成立时的处理方式。 + +句子描述完成状态时，必须给出可观察或可判断的完成标志。 + +## 二、名词与术语 +### 2.1 术语来源优先级 + +按以下顺序确定文档中的术语： + +原型界面上实际显示的页面名、模块名、按钮名、字段名和状态名。 + +已确认的产品需求、功能定义及业务术语表。 + +行业内含义明确且与当前业务一致的通用术语。 + +无法从以上来源确认的术语，标记为「待确认」，不得自行创造。 + +### 2.2 界面名称使用规则 + +界面已有名称时，文档必须使用原名称，不得随意改写、缩写或替换同义词。 + +首次提及界面元素时，使用完整名称。 + +同一对象在全文中必须使用同一名称。 + +页面名、模块名、控件名、字段名和状态名不得混用。 + +界面名称与业务概念不一致时，分别说明界面名称和业务概念，不得强行合并。 + +原型中没有名称的元素，不得擅自赋予正式名称；必要时使用位置描述并标记「待命名」。 + +引用按钮、菜单、字段或状态时，使用其实际显示文本，并通过引号或上下文明确其为界面名称。 + +### 2.3 新术语与未知术语处理 + +新术语必须有明确的业务定义、使用范围和来源。 + +同一概念存在多个叫法时，确定一个标准名称，其余叫法仅在必要时作为别名说明。 + +不得通过拼接常见词语创造未经定义的产品术语。 + +不得将技术实现名称直接当作用户可见的功能名称，除非产品资料明确采用该名称。 + +不得把个人理解、推测或临时命名写成已确认的业务定义。 + +无法确认术语含义时，记录待确认事项，不得通过上下文猜测后直接定稿。 + +### 2.4 指代与缩写 + +不使用指向不明确的「它」「这个」「相关内容」「上述功能」。 + +可以唯一定位对象时，直接使用对象名称。 + +缩写首次出现时，应给出中文全称及必要的英文全称。 + +缩写在全文中必须保持一致，不得交替使用全称、简称和自造简称造成歧义。 + +## 三、禁用清单 + +以下词语和句式在正式产品文档中一律禁用。确需表达对应含义时，必须替换为明确、可验证的描述。 + +### 3.1 聊天式表达 + +「我们可以……」 + +「你可以……」 + +「用户只要……就行」 + +「点一下……」 + +「然后就……」 + +「这个地方……」 + +「这里的话……」 + +「其实就是……」 + +「简单来说……」 + +「大概是……」 + +「差不多……」 + +「之类的……」 + +「等等」「诸如此类」 + +### 3.2 空泛动词与模糊表达 + +「搞定」「弄好」「处理一下」 + +「做一下」「操作一下」「配置一下」 + +「支持相关操作」 + +「进行相应处理」 + +「展示相关信息」 + +「提供便捷能力」 + +「实现快速处理」 + +「优化体验」 + +「提升效率」 + +「满足用户需求」 + +「智能处理」「自动优化」——未明确处理规则时禁用。 + +「实时更新」「快速响应」——未定义时效或判定标准时禁用。 + +「灵活配置」「多种方式」「丰富内容」——未列出具体范围时禁用。 + +### 3.3 无明确依据的程度词 + +「非常」「特别」「极其」 + +「十分方便」「十分简单」 + +「更加友好」「更加完善」 + +「高效」「便捷」「流畅」 + +「强大」「先进」「全面」 + +「无缝」「极致」「完美」 + +「大幅提升」「显著改善」 + +「一键完成」「秒级完成」——未验证对应行为或性能时禁用。 + +### 3.4 含糊的指代与范围词 + +「相关页面」「对应位置」——未给出具体名称或路径时禁用。 + +「相应内容」「相关信息」——未说明具体对象时禁用。 + +「适当提示」「必要时处理」——未定义触发条件时禁用。 + +「部分数据」「一些情况」「某些用户」——未限定范围时禁用。 + +「正常情况下」「特殊情况下」——未定义条件时禁用。 + +「根据实际情况」「视情况而定」——未说明判断规则时禁用。 + +「等」「等等」——用于省略必要枚举项时禁用。 + +### 3.5 空泛承诺与无依据结论 + +「确保用户满意」 + +「保证数据准确」 + +「避免所有错误」 + +「全面覆盖用户场景」 + +「系统会自动处理所有问题」 + +「用户能够轻松完成全部操作」 + +「该功能已经成熟稳定」 + +「该设计符合所有用户习惯」 + +以上表述只有在具备明确的验证依据、适用范围和判定标准时，才可以改写为具体的事实或约束。 + +### 3.6 不合格句式 + +「用户进入页面后，可以看到很多信息。」 + +「系统会根据情况进行相应处理。」 + +「用户点击按钮，然后系统就会完成操作。」 + +「如果有问题，系统会给出提示。」 + +「该功能主要用于提升用户体验。」 + +「支持多种输入方式，满足不同用户需求。」 + +「出现异常时，用户可以自行处理。」 + +「页面包含账号、内容、数据等相关模块。」 + +这些句式缺少具体对象、条件、行为、结果或处理规则，不得直接用于正式文档。 + +## 四、对错对照 +### 第 1 组：操作说明 + +不规范： 用户点一下提交按钮，然后就可以完成创建。 + +规范： 用户点击「提交」按钮后，系统校验表单必填项。校验通过时，系统创建记录并显示提交结果。 + +### 第 2 组：页面说明 + +不规范： 这里可以看到账号的各种信息，方便用户进行管理。 + +规范： 「账号列表」显示账号名称、所属平台、运营状态和最近更新时间。用户可通过列表操作入口查看账号详情。 + +### 第 3 组：输入规则 + +不规范： 用户填写相关信息就行，格式不对的话系统会提示。 + +规范： 用户必须填写「账号名称」字段。字段长度限制及允许字符范围为待确认。输入校验失败时的提示文案和恢复方式为待确认。 + +### 第 4 组：异常处理 + +不规范： 如果操作失败，系统会进行相应处理，用户重新试一下即可。 + +规范： 操作失败时，系统应显示失败原因和可执行的恢复操作。失败提示、重试条件及数据保留规则尚未确认。 + +### 第 5 组：功能价值 + +不规范： 该功能可以帮助运营人员高效地管理内容，提升工作效率。 + +规范： 「内容列表」集中显示内容标题、发布平台、审核状态和计划发布时间。运营人员可在列表中筛选内容，并进入详情页查看单条内容。 + +## 五、自检清单 + +每句话必须逐项检查。任一项不通过，必须修改后再提交。 + +语体检查： 是否存在聊天用语、口号、营销话术或主观评价？存在即不通过。 + +单义检查： 一个句子是否包含多个可独立执行的动作或多个独立结论？存在且未清晰拆分时不通过。 + +对象检查： 是否能明确指出句子描述的用户、系统、页面、控件、数据或业务对象？不能明确指出时不通过。 + +术语检查： 页面名、模块名、控件名和状态名是否与原型一致？不一致且未经说明时不通过。 + +来源检查： 是否出现没有来源、没有定义或未经确认的术语？存在且未标记时不通过。 + +动作检查： 是否明确写出发生了什么操作或系统行为？仅写「处理」「支持」「实现」而没有具体行为时不通过。 + +条件检查： 是否存在「如果」「当」「在……情况下」等条件表达，却没有说明对应结果？存在即不通过。 + +结果检查： 是否声称操作完成，却没有可观察的结果或完成标志？存在即不通过。 + +边界检查： 是否使用「多种」「部分」「适当」「相关」等词，却没有给出具体范围？存在即不通过。 + +事实检查： 是否将模拟行为、计划能力或未验证规则写成已实现事实？存在即不通过。 + +异常检查： 是否只写「提示用户」或「进行处理」，没有明确异常条件和恢复路径？存在即不通过。 + +独立阅读检查： 不查看原型的产品、开发和设计人员，是否能根据描述定位对象并理解行为？不能时不通过。 + +一致性检查： 同一对象在全文中是否存在多个未经定义的名称？存在即不通过。 + +精简检查： 删除某个词句后，事实、条件、动作或结果是否完全不受影响？若不受影响，应删除该词句。 + +## 六、最终验收规则 + +文档中的每句话都必须通过第五节自检。 + +所有界面名称必须有原型或已确认资料作为依据。 + +所有业务规则必须有明确来源；无来源的规则标记为「待确认」。 + +所有操作说明必须明确操作对象和可观察结果。 + +所有异常说明必须明确触发条件、反馈和恢复方式；尚未定义的内容标记为「待确认」。 + +禁用清单中的表达不得直接出现在正式说明正文中，必要的引用、规则举例和本规范自身的说明除外。 + +任何无法判断真假的描述均不得作为已确认事实写入文档。 + +文档以准确、可定位、可验证、可独立阅读为合格标准，不以篇幅或修辞作为质量标准。 diff --git a/product-planning/references/_留痕/N6-20261016/references/stage-requirements/SKILL.md b/product-planning/references/_留痕/N6-20261016/references/stage-requirements/SKILL.md new file mode 100644 index 0000000..550db7f --- /dev/null +++ b/product-planning/references/_留痕/N6-20261016/references/stage-requirements/SKILL.md @@ -0,0 +1,172 @@ +--- +name: stage-requirements +description: 产品规划第②段，产品功能。只做一件事：把①段《使用场景》（`1e-使用场景.md`）细化成功能清单（做哪些 / 不做哪些 / 优先级），并钉死页面骨架（《界面布局》：有哪几页、每页几个板块、板块怎么排、跨页关系）。当用户要写②段两份、列产品功能、定优先级、梳理功能、定页面与板块布局，或说"只做产品功能"时调用。 +--- + +# ② 产品功能 + +回答「要做哪些产品功能、哪些明确不做、页面骨架怎么排」。产出两份： +`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单）＋ `docs/pm/<项目>/prd/2b-界面布局.md`（页面骨架）。 + +> 段名与①「产品需求」构成 `产品需求 → 产品功能 → 界面交互 → 原型说明` 的对称链，四段各占一个词（产品 / 功能 / 界面 / 说明），无一词共用（2026-10-02 用户定）。旧名「需求与结构」「界面与交付」已废。 +> +> 与①段的分界：①回答「要解决什么问题、用户怎么用它」，②回答「要做哪些功能、长成什么骨架」。判据看文档主体 —— 主体是功能条目的有无与优先级、页面与板块骨架，归②；主体是问题、用户、取证与取舍理由，归①。 +> +> ⭐ 2026-10-06 用户定案：本段收窄为「只细化功能」。2026-10-07 用户定案「2 产品功能 和 界面布局不就是两个文档嘛」，两件事各成一份：产品功能（做什么）＋ 界面布局（长什么样）。（①段侧的定案原话与 grill 归属见 `stage-discovery`，本段不复述。） +> +> 本段就这两份：`prd/2a-产品功能.md`（功能清单）＋ `prd/2b-界面布局.md`（页面骨架）。 +> +> 别处的内容在本段怎么落地：状态流转与优先级都写进每条功能自己，不单独成文；用户故事取①段《使用场景》（`1e-使用场景.md`），本段按它推功能；grill / 压测在①段 1a（全场唯一一份 `grill-me`）；风险取①段《产品策略》的「假设与风险」。 +> +> （历史：本段收窄前的产出清单与其去向 → `_留痕/②段-已删除产出与方法论.md`） + +## ⭐⭐ ②—③ 交接口（唯一权威处 · 改边界只改这一块 · 2026-10-06 用户定案） + +> 🔴 「②段管什么、③段管什么」**只在本节定义一次**。本段其余章节、总入口 `product-planning/SKILL.md`、 +> `stage-discovery` 与 `stage-delivery` 的 `SKILL.md`、③段 `references/execution-runbook.md` 与 +> `references/layouts-tooling.md`，提到这条边界时一律**引用本节的行名**，⛔ 不许再复述清单。 +> 为什么立这一块：同型的复述病已经造成过真事故 —— 停线规则被三段写成「三种、②段写成「四种」， +> 两边长期漂着而没有任何门禁会报。单一可信源才拦得住。 +> 用户原话（本节的唯一出处，别处不再抄）：「3 是负责设计和交互，页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子」。 + +口径：②段钉骨架，③段做皮肉。 + +| 归②段（必须在本段定死） | 归③段（⛔ ②段不许写） | +|---|---| +| 有哪几页 | 配色 / 字体 / 间距 / 组件样式 / 动效 | +| 每页几个板块、板块怎么排 | 每个板块的视觉实现（怎么好看、怎么对齐、什么层次） | +| 跨页关系（怎么跳转） | 每个板块的交互行为（点哪、什么反馈、何时不可点） | +| 每页的主操作是什么 | 状态与空态的具体呈现 | +| 每条信息在哪一档承载（主屏常驻 / 可点入） | 响应式怎么变 | + +> ⭐ 骨架是判断基准，必须在②段定死。旧口径把「有哪几页」留在③段，结果就是③段做一版一个样，②段无从判断改得对不对。 +> ⛔ 交给③段时骨架是冻结的：③段不许新增 / 移动 / 删除板块，缺板块要回②段改。 +> 「归③段」那一列的六个词就是本段的**零视觉词红线**：本段其余章节与 `references/create-prd.md` 提到它时， +> 一律写成「见 §②—③ 交接口 的『归③段』列」，⛔ 不再逐处抄这六个词。 + +## 本段职责（2026-10-06 按「只细化功能」重划） + +本段回答一个问题：把①段的使用场景细化成哪些功能，这些功能长成一个什么骨架。拆成两问（原三问）： + +| 问 | 内容 | 落点 | +|---|---|---| +| 有哪些功能、优先级如何、什么不做 | 从每条使用场景推出功能条目；每条带优先级、状态流转、验收要点 | `2a-产品功能.md` | +| 这些功能长成什么骨架 | 有哪几页、每页几个板块、板块怎么排、跨页关系 | `2b-界面布局.md` | + +> ⭐ 本段产物的主体是功能条目的有无与优先级，这也是「产品功能」这个名字的依据。实测本项目 26 条功能定义全在②段、一条不在 research。 +> ⛔ 本段不许重开需求：需求澄清、grill 反问、取证都在①段做完了。本段假定需求已成立，只做功能取舍。 +> ⭐ 功能按使用场景组织（2026-10-06 用户定案），一条使用场景下可能放跨多个页面的功能。用户原话：「功能可以分使用场景梳理（可能是跨页面的）」。不按页面组织 —— 按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上。 + +## 2a 产品功能 + +| 子步 | 读 | 产出 | +|---|---|---| +| 2a 产品功能 | `references/create-prd.md` | `docs/pm/<项目>/prd/2a-产品功能.md` | + +回答：要做哪些功能、哪些明确不做、每条什么优先级、每个功能自身怎么流转。 + +## 2b 界面布局 + +| 子步 | 读 | 产出 | +|---|---|---| +| 2b 界面布局 | `assets/diagram-design/SKILL.md`（第三方 skill 整树保留，其 `references/`、`scripts/`、`assets/` 路径均相对该目录解析） | `docs/pm/<项目>/prd/2b-界面布局.md` | + +回答：有哪几页、每页几个板块、板块怎么排、跨页关系怎么跳。 + +> 顺序是 2a → 2b：布局是功能清单的空间展开，功能还没定就画布局等于凭空发明版面。 +> ⛔ 2a 之前不再需要压测步骤，压测已前移①段 1a 的 B 节。 + +### 功能清单怎么组织（逐条可核） + +每个功能条目必须带齐这几样： + +| 字段 | 写什么 | 判据 | +|---|---|---| +| 功能名 | 一句话说清做什么（动词开头的用户语言） | ⛔ 不写实现名 | +| 来自哪条场景 | 追回①段《使用场景》（`1e-使用场景.md`）的编号 | ⛔ 追不回的条目该砍 | +| 优先级 | P0 / P1 / P2 | 见下方「优先级」 | +| 状态流转 | 这个功能自身有哪几个状态、怎么迁移（不适用就写「无状态」） | ⛔ 不许省成空白 | +| 验收要点 | 怎么算做完（可观察） | ⛔ 不写「体验好」这类 | +| 跨哪些页面 | 这个功能在骨架的哪几页上发生 | 可为多页 | + +优先级（⛔ 不许凭空打分，见硬约束）： +- P0：不做则①段某条使用场景整条办不成 +- P1：不做则场景能办成但要多绕（本可用一次点击，变成三步） +- P2：不做不影响场景办成，只是更好用 + +> 优先级判据 = 一句可复述的话。本项目没有数据源，不填数字。 + +### 2b 界面布局怎么写 + +本份专管界面骨架，⛔ 不写功能条目的有无与优先级（那是 `2a-产品功能.md`）。一句话分工：`2a` 管「做哪些事」，`2b` 管「这些事落在哪几页、每页长什么结构」。 + +| 问 | 回答 | 内容 | +|---|---|---| +| 页面关系 | 有哪几页、门开在哪、**新功能放在已有产品的哪一页** | 页面清单、页面流转、导航、**已有产品的页面 ＋ 新增块** | +| 页面内布局 | 房间里家具怎么摆 | 每页的板块清单 ＋ 排列顺序（wireframe 灰块粒度） | + +> ⭐ 拆成两份是 2026-10-07 的用户定案。旧写法一份装两半，同一件事要写两遍（比如 `header / side / footer` 既像页面框架又像页内板块）；拆开后各自只写自己那一侧，正好逼着把边界写明确。 +> 🔴 防重写规则（拆开后必须守）：页面级框架（`header / side / footer`）只在 `2b` 写一次；`2a` 的功能条目里只许出现「跨哪些页面」，⛔ 不许描述页面长什么样。 +> ⚠️ 粒度：本段给灰块框图（有哪些块、什么顺序），⛔ 不给视觉（颜色、字体、间距、圆角、层次）。视觉类六词（见 §②—③ 交接口 的『归③段』列），本段（含布局）仍不许写。 +> ⚠️ 旧 `ux/diagrams/system-architecture.html` 画的是系统组件之间的关系，属实现视角，已改名。本段要的是页面与板块，属产品视角，⛔ 不许再叫「系统架构」。 + +## 硬约束 +- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。 + +- ⭐ 本段不是压测入口（2026-10-06）：`grill-me` 全场只有①段一份，火力点已扩到覆盖「做成什么样、状态怎么流转」。⛔ 本段不许再开一轮反问 —— ①段 `1a-需求文档.md` 的决策表就是本段的压测输入。用户始终不回应时①段怎么处理，本段照旧继承，但不再自己去问。 +- ⭐ 假设照旧继承，但账在①段：`1a-需求文档.md` 带进来的每条 `【假设】`，在②段落盘时逐条给结论，只允许三种归宿 —— 已确认（写明确认人与时间）｜待实现且已排定确认时机（写明「在第几步落地前必须问」）｜`【已按假设落地】`（写清影响面 + 回退口径）。⛔ 第四种（既未确认、已进实现、又无落地说明）不许带进本段。 + - ⭐ 引用假设必须带状态：本段任何一条功能 / 状态流转 / 分档，只要依据是某条假设，就在括号里带上该假设的当前状态（`（依据 Q7 · 已确认）`、`（依据 Q10 · 【已按假设落地 · 影响面：每版全量复制 → 版本目录体积】）`）。下游③段据此判断这条能不能当硬约束用。 + - ⭐ 假设与实测要回头对账：凡靠假设得出的结论，一旦下游跑出实测结果，必须回填并改状态。实测踩坑：`PRD.md:132` 假设 3「单文件 HTML 在 `file://` 下能双击打开（③段需实测）」标着待实测，而③段早已实测了 16 版，事实成立却没人回填。 +- ⭐ 待确认 / 暂缓项必须带回收三字段（2026-10-02）：本段任何「待确认 / 暂缓 / 待定」条目必须同时写 复核人 ＋ 复核时机 ＋ 结论落点（哪个文件哪一节），三字段缺一不许落盘。⛔ 只写「暂缓」等于无限期搁置。 +- 「不做 / 移出」必须逐条核对，不许自行裁剪：写②段前、落盘后各做一次 —— 把②段里每一条「不做 / 移出 / 暂缓」与 `1a-需求文档.md` 的已拍板项逐条对照。凡涉及已拍板项，一律不得自行裁剪或改口径，必须列成「与已定决策的差异」表（原条目 / 原口径 / 拟改口径 / 理由）交用户显式确认。只写「已核对无冲突」不算核对，要给出对照过的条目数。 +- ⭐ 每条功能必须能追回①段《使用场景》（`1e-使用场景.md`）：追不回的功能就要么补一条场景、要么砍掉。这是本段唯一的功能有无判据，代替凭空打分。 +- ⭐ 状态流转写在功能条目里，⛔ 不再单独成文（2026-10-06）：每个功能条目自带「状态流转」字段。六项治理照旧全覆盖（失败恢复路径、持久化范围、并发冲突、幂等、超时迁移目标、不可逆操作二次确认），只是落点从独立文档移进功能条目。 + - ⭐ 状态放不到任何功能上的中间态，要么删掉，要么补一个功能条目让它服务。 +- ⭐ 骨架必须给全（2026-10-06）：②段的《界面布局》必须给全 §②—③ 交接口 的「归②段」列那几样，逐条对应。⛔ 缺任何一样，③段就没有方向。 + - 信息承载分档的判据：「删掉它，主操作还做得成吗」—— 答「做得成」就只能进「可点入」。⛔ 「能读到」= 可点入，不等于主屏常驻；不许以「②段要求能读到」为由把信息留在主屏。 +- ⛔ 本段（含布局）不许写视觉（六词清单见 §②—③ 交接口 的『归③段』列），一个字都不许出现。 +- ⭐ 文档前面必须配图（2026-10-15 用户令）：本段落盘的每份文档，正文（第一张表 / 第一小节）之前必须先给一张图 —— 本段画《页面与功能结构图》；用 `diagram-design` 画，⛔ 手写 Mermaid。图是正文内容，⛔ 不写成标题旁边或标题下面的注解小字。 +- 段内不反问，做完直接往下走。停线规则（哪几种情况停、怎么判）见 `product-planning` 的「执行规则」—— ⛔ 本段不复述，免得两处漂。 +- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。 + +## 完成标准 + +- `2a-产品功能.md` 与 `2b-界面布局.md` 两份都在，且只有这两份（⛔ 不许再产出 `grill-decisions` / `user-stories` / `priorities` / `pre-mortem` / `state-machine` / `diagrams` 六份中的任何一份；⛔ 也不许再退回单份 `PRD.md`） +- ②段的「不做 / 移出」清单逐条对照过①段已拍板项，差异行为 0 或每一行都已获用户显式确认（附对照条目数，不得只写「无冲突」） +- 功能清单每条带齐「功能名 / 来自哪条场景 / 优先级 / 状态流转 / 验收要点 / 跨哪些页面」六字段；⛔ 追不回①段场景的条目为 0 +- 状态流转六项治理全覆盖（失败恢复 / 持久化 / 并发 / 幂等 / 超时 / 不可逆二次确认），且落在功能条目内 +- 《界面布局》给全 §②—③ 交接口 的「归②段」列（含分档判据回答） +- ⛔ 全文零视觉词（六词清单见 §②—③ 交接口 的『归③段』列） +- 每条假设都有归宿（三选一，无第四种）；凡依据假设的功能 / 状态流转 / 分档，条目里都带上了假设状态标注 +- ⭐ 2a 与 2b 两份前面都配了图（用 `diagram-design`，⛔ 无手写 Mermaid） +- 本段所有「待确认 / 暂缓」条目都带齐 复核人 / 复核时机 / 结论落点 三字段 +- ⭐ 两份都过了「说人话」内容准则（源技能、判据与门槛见 `product-planning` 的「执行规则」内容准则条）；段末报告须写明「已过内容准则，评分 X/50」 + +## 反面清单 + +- ⛔ 在本段重开一轮 grill 反问（2026-10-06）：反问已整套前移①段 1a，本段只细化功能 +- ⛔ 产出本段两份之外的文档（本段只 `2a` 与 `2b`，白名单由 `check_naming.py` 机器判） +- ⛔ 把「产品功能」与「界面布局」又塞回一份（2026-10-07 用户定案：这就是两个文档） +- ⛔ `2a` 里描述页面结构 / `2b` 里写功能条目的有无与优先级（越界即重写） +- ⛔ 按页面组织功能清单（2026-10-06）：功能要按使用场景组织，一条场景可跨多页；按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上 +- ⛔ 凭空给功能打分（Importance × Satisfaction / ICE / RICE）：没有数据源。优先级只能是 P0/P1/P2 + 一句可复述的判据 +- ⛔ 功能条目追不回①段《使用场景》（`1e-使用场景.md`）：追不回就要么补场景、要么砍条目 +- 用「移出第一版 / 不做」自行砍掉已拍板项，或只声称「已核对无冲突」却不列对照条目数 +- 在本段重开需求验证（该做取证与需求定义的是①段；本段假定需求已成立，只做功能取舍） +- ⛔ 骨架给不全（2026-10-06）：只给页面清单、不给每页板块与排列，或只给布局、不给跨页关系 —— ③段拿不到方向，就会一版一个样 +- ⛔ 把某条信息标为「主屏常驻」却答不上「缺了主操作就做不成事」：按判据应归「可点入」 +- 状态流转只画正常路径，不管失败与并发；或状态放不到任何功能条目上（凭空中间态） +- ⛔ 在本段写视觉（清单见 §②—③ 交接口）—— 那是③段 +- 越界去出原型或写说明文档（那是第③④段） +- 把 `【假设】` 原样带进②段当既定事实；或假设已被实现却从不回填状态 +- 只写「暂缓」而不给复核人 / 复核时机 / 结论落点 —— 等于让这条永远放着 +- ⛔ 两份没过「说人话」内容准则就落盘 —— 口径与门槛见 `product-planning` 的「执行规则」内容准则条 +- ⛔ 改本技能包的规则文件、却不过「说人话」这一关（2026-10-07）：规则和产出同一把尺子 —— 口径见 `product-planning` 的「执行规则」内容准则条 + +## 本段读什么、守什么 + +- 方法论两份：`references/create-prd.md`（功能清单）、`references/state-machine.md`（六项治理清单仍要读，落点变成功能条目内）。 +- 绘图资产：`assets/diagram-design/`（整树保留，供画布局图）。 +- 贯穿纪律：同一件事只写一遍 —— 同一批人 / 同一批场景若在①②两段各写一份，必然打架。 + +📎 本段收窄前的产出清单与其去向（含方法论去留）见 `_留痕/②段-已删除产出与方法论.md` —— 正文不展开；防复活由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` / `WHITELIST` 机器判。 diff --git a/product-planning/references/_留痕/N6-20261016/references/stage-requirements/references/create-prd.md b/product-planning/references/_留痕/N6-20261016/references/stage-requirements/references/create-prd.md new file mode 100644 index 0000000..35e538e --- /dev/null +++ b/product-planning/references/_留痕/N6-20261016/references/stage-requirements/references/create-prd.md @@ -0,0 +1,133 @@ +# Create a Product Requirements Document（②段专用版） + +> 本文件由模型按需加载，没有斜杠命令。 +> 产出：`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单）。 +> ②段是两份：功能清单归本份，页面骨架归 `prd/2b-界面布局.md`，不归本份。 +> +> ⭐ 2026-10-06 用户定案改版：本段收窄为「只细化功能」，产出从 7 份收成 1 份。 +> 上游的 8 段式模板（Summary / Contacts / Market Segment / Value Proposition / Release…）大部分已不适用 —— 它是给「面向市场、要售卖、有干系人」的产品写的；本项目与同类单机自用 / 工具型产品没有这些内容，硬填就是编。保留的部分见下。 + +## 本②段写两件事 + +| # | 写什么 | 判据 | +|---|---|---| +| 一 | 功能清单 —— 做哪些、不做哪些、每条什么优先级 | 每条能追回①段《使用场景》（`1e-使用场景.md`） | +| 二 | 界面布局 —— 与「归②段」列逐条对应（清单见 `SKILL.md` §②—③ 交接口） | ③段拿着它就有方向 | + +> 不写：视觉（六词清单见 `SKILL.md` §②—③ 交接口 的『归③段』列）、需求取证（归①段）、grill 反问（归①段）、用户故事（归①段《使用场景》（`1e-使用场景.md`））。 + +## 一、功能清单 + +### 组织方式：按使用场景，不按页面 + +依据是①段《使用场景》（`1e-使用场景.md`）的每一条。一条场景下可放跨多个页面的功能。 + +用户原话（2026-10-06）：「功能可以分使用场景梳理（可能是跨页面的）」。 + +> 按页面组织会把跨页场景切碎，也和①段《使用场景》对不上。对不上就追不回来源，功能就没有由来。 + +### 每条功能的六字段（缺一不算完成） + +| 字段 | 写什么 | +|---|---| +| 功能名 | 一句话说清做什么（动词开头的用户语言），不写实现名 | +| 来自哪条场景 | 追回①段《使用场景》（`1e-使用场景.md`）的编号 | +| 优先级 | P0 / P1 / P2（判据见下） | +| 状态流转 | 这个功能自身有哪几个状态、怎么迁移；无状态就写「无状态」，不留空 | +| 验收要点 | 怎么算做完（可观察），不写「体验好」 | +| 跨哪些页面 | 这个功能在骨架的哪几页上发生（可多页） | + +### 优先级判据（不许凭空打分） + +| 级 | 判据 | +|---|---| +| P0 | 不做则①段某条使用场景整条办不成 | +| P1 | 不做则场景能办成但要多绕（本可一次点击，变成三步） | +| P2 | 不做不影响场景办成，只是更好用 | + +> 优先级就是一句可复述的话。本项目没有数据源，不填数字 —— 数字一旦填进去，就会一路传到功能条目。 + +### 「不做」清单（必须逐条对照，不许自行裁剪） + +写②段前、落盘后各做一次：把每一条「不做 / 移出 / 暂缓」与①段 `1a-需求文档.md` 的已拍板项逐条对照。 + +凡涉及已拍板项，一律不得自行裁剪或改口径，必须列成「与已定决策的差异」表： + +| 原条目 | 原口径 | 拟改口径 | 理由 | +|---|---|---|---| + +只写「已核对无冲突」不算核对，要给出对照过的条目数。 + +## 二、界面布局 + +### 为什么两半合成一份 + +一句话：信息架构管「页面之间」，布局管「页面之内」。 + +| 半 | 回答 | 内容 | +|---|---|---| +| 页面关系 | 有哪几页、门开在哪、**新功能放在已有产品的哪一页** | 页面清单、页面流转、导航、**已有产品的页面 ＋ 新增块** | +| 页面内布局 | 房间里家具怎么摆 | 每页的板块清单 + 排列顺序（wireframe 灰块粒度） | + +> 不拆两份的理由：参考图里的 `header / side / footer` 是页面框架，正好卡在「之间」与「之内」的交界。拆两份必然出现「页面 P1 有 header」写两遍，而同一件事写两遍就是打架的起点，本项目反复踩这个坑。 + +### 必须给全的五样（缺一样③段就没方向） + +「归②段」那一列就是这五样，逐条一一对应（定义见 `SKILL.md` §②—③ 交接口）。三条操作细节补充： + +1. 每页板块给到 wireframe 灰块粒度 —— 有几个块、从上到下什么顺序，⛔ 不含视觉。 +2. 页面流转要写清「谁跳到谁、什么条件下」，⛔ 不写「用户可自由导航」这类空话。 +3. 在已有产品上做加法时，「页面关系」要写出「**已有产品的页面 ＋ 新增块**」，⛔ 不把「往已有页加一块」写成「新增一页」；原有功能要在骨架里**显式保留**（③段照它做逐项回归）。 + +### 信息承载分档（判据只有一条） + +| 档 | 定义 | +|---|---| +| 主屏常驻 | 零点击可见 | +| 可点入 | 一次点击内可达 | + +唯一判据：「删掉它，主操作还做得成吗」—— 答「做得成」，就只能进「可点入」。 + +> 「能读到」= 可点入，不等于主屏常驻。不得以「②段要求能读到」为理由把信息留在主屏。 +> 四种禁用免死金牌（理由里只要出现，一律判「不上屏」，哪怕后面跟着「但是」）：① 「但②段要求能读到」；② 「留（产品级约束）」；③ 「但不完整 / 不专业」；④ 「将来可能需要」。 +> 实战教训：本项目首版②段只说「不写结构」，③段把「必须能读到」全理解为主屏常驻，一屏铺 5 类信息，页面成了「信息墙」，被判定为「最多算一个产品框图」。 + +### 页型一句（仍需写） + +本产品的界面是营销页（访客看一眼就下决心）还是工具型页面（用户把活干完）—— 写一句判型加依据。 + +> 为什么必须写：③段的版式供给偏落地页向。不说页型，③段就会套错骨架，长成「标题上方一行小字 + 大标题 + 下方一行灰字」，判据全绿、排版难看。本项目实测踩过。 +> 只写一句判型，不许写「用哪个骨架 / 哪个区块」。 + +## 三、仍需保留的旧模板要素（按需，不硬填） + +| 旧 8 段式里的段 | 处置 | +|---|---| +| Summary / Background / Objective | 可保留，但压成很短一段 —— 给下游快速对齐用 | +| Contacts | 删 —— 单机自用产品没有干系人名单 | +| Market Segment | 删 —— 归①段《用户画像》 | +| Value Proposition | 删 —— 归①段 | +| Solution → Key Features | 保留 —— 就是本②段的「功能清单」 | +| Solution → UX/Prototypes | 改为「界面布局」—— 只给灰块骨架，不出视觉稿 | +| Solution → Assumptions | 保留 —— 假设台账与归宿（口径见 SKILL.md 硬约束） | +| Release | 可选 —— 第一版做什么 vs 后面做什么；不写具体日期 | + +## 四、通用要求 + +- 写给人看：短句、少术语，能读给不熟悉项目的人听懂。落盘前必须过「说人话」内容准则（源技能、门槛与五条核心原则见 `product-planning` 的「执行规则」内容准则条）。 +- 每条都能追来源：功能追①段场景，假设带状态标注，判据给一句话。 +- 全文零视觉词（六词清单见 `SKILL.md` §②—③ 交接口 的『归③段』列），一个字都不许出现。 +- 保留修订记录：改了实现必须回填条款正文，不能只在修订记录里写。 + +## 落盘 + +两份：`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单）＋ `prd/2b-界面布局.md`（页面骨架）。 + +## 附：输出检查 + +- [ ] 每条功能都能追回①段《使用场景》（`1e-使用场景.md`）的某一条 +- [ ] 每条功能六字段齐全（功能名 / 来自哪条场景 / 优先级 / 状态流转 / 验收要点 / 跨哪些页面） +- [ ] 优先级没填数字，只用 P0 / P1 / P2 加一句可复述的判据 +- [ ] 「不做」清单与①段已拍板项逐条对照，并给出对照过的条目数 +- [ ] 界面布局五样给全（页面清单 / 页面流转 / 每页板块清单与排列 / 每页主操作 / 信息分档） +- [ ] 全文零视觉词（见 `SKILL.md` §②—③ 交接口 的『归③段』列） diff --git a/product-planning/references/_留痕/N6-20261016/references/stage-requirements/references/state-machine.md b/product-planning/references/_留痕/N6-20261016/references/stage-requirements/references/state-machine.md new file mode 100644 index 0000000..763360a --- /dev/null +++ b/product-planning/references/_留痕/N6-20261016/references/stage-requirements/references/state-machine.md @@ -0,0 +1,82 @@ +# 状态机（State Machine） + +> 本文件由模型按需加载，没有斜杠命令。 +> +> ⭐ 2026-10-06 变更：本份不再产出独立文档。状态流转整合进②段的功能清单 —— 每个功能条目自带一个「状态流转」字段。 +> 本份保留，是因为它给出的六项治理清单（失败恢复 / 持久化 / 并发 / 幂等 / 超时 / 不可逆二次确认）仍要逐项覆盖，只是落点从 `ux/state-machine.md` 移进 `prd/2a-产品功能.md` 的功能条目内。 +> 本份只作方法论读，落点是功能条目内的「状态流转」字段。 + +## 何时用 + +- 功能有异步或长流程（草稿 / 排队 / 生成中 / 失败 / 重试 / 完成） +- 需要写清失败之后怎么办（重试 / 降级 / 人工接管） +- 前端要看「什么状态下能点什么」 + +## 分工边界（重要） + +本份只给状态迁移的判据与治理清单。 + +架构图、流程图、时序图、用户旅程图、泳道图请用 `assets/diagram-design/` —— 它有 39 种编辑级图型，且输出自包含 HTML+SVG。状态迁移的守卫 / 副作用 / 持久化 / 并发治理没有现成开源 skill 覆盖，所以留在本份。 + +## 主产出：状态迁移表（贴在功能条目内） + +| 状态 | 含义 | 允许事件 | 守卫条件 | 迁移到 | 副作用 | +|---|---|---|---|---|---| +| idle | 未开始 | submit | 参数合法 | queued | 创建任务 | +| queued | 排队中 | start / cancel | — | running / idle | — | +| running | 生成中 | done / fail / cancel | — | succeeded / failed / idle | 写日志 | +| failed | 失败 | retry | 重试次数 < 3 | queued | 计数 +1 | +| succeeded | 完成 | edit / export | — | idle | 存版本 | + +字段定义： + +- 状态：英文小写下划线，不中英混写，便于直接落到代码 +- 允许事件：不在该行的事件一律视为非法，必须显式拒绝，不能静默忽略 +- 守卫条件：不加守卫就会出的错（重复提交、配额超限、并发编辑、权限不足） +- 迁移到：目标状态，只写一个，多目标用守卫条件拆开 +- 副作用：迁移时必须做的事（落库、发通知、计费、埋点） + +> ⭐ 不适用时写「无状态」：某些功能确实没有状态流转（如「看一版截图」）。不许把这一栏留空 —— 留空与「没想」不可区分，写「无状态」是合格答案。 + +## 必答清单（漏一项即缺陷） + +1. 失败恢复路径：每个失败态给出三种之一 —— 自动重试（次数 / 退避策略）、降级（降级成什么）、人工接管（入口在哪） +2. 持久化：哪些状态要落库？刷新 / 断线 / 换设备后能否恢复？不能恢复的必须显式说明 +3. 并发冲突：同一资源被两个入口同时修改怎么办（乐观锁 / 队列串行 / 后者覆盖并提示） +4. 超时：每个中间态的最长停留时间，超时后迁移到哪 +5. 幂等：重复提交同一请求的结果是什么 +6. 不可逆操作：删除、发布、扣费类迁移要标注「需二次确认」 + +## 死状态禁令 + +- 每个状态必须有出口，终态也要能「再次开始」 +- 不允许「其他」「未知」这类兜底状态 +- 不允许没有触发事件的自动漂移（超时迁移不算，但必须显式定义） + +## 速览图 + +仅作沟通速览。需要正式交付级图，交给 `diagram-design`。 + +```mermaid +stateDiagram-v2 + [*] --> idle + idle --> queued: submit + queued --> running: start + running --> succeeded: done + running --> failed: fail + failed --> queued: retry + succeeded --> idle: edit +``` + +## 附：输出检查 + +- [ ] 每条迁移都有触发事件、无自动漂移，且放在具体功能条目上（无凭空中间态）；无状态的功能显式写「无状态」 +- [ ] 每个失败态都有恢复路径（重试 / 降级 / 人工接管） +- [ ] 持久化范围明确：哪些状态落库，刷新 / 断线 / 换设备后能否恢复 +- [ ] 并发冲突有处理方式 +- [ ] 超时策略明确：每个中间态最长停留多久、超时后迁到哪 +- [ ] 不可逆操作（删除 / 发布 / 扣费）已标注「需二次确认」 + +## 落盘 + +落点是 `docs/pm/<项目>/prd/2a-产品功能.md` 的功能清单内 —— 每个功能条目自带一个「状态流转」字段，按上表格式写；无状态的功能写「无状态」。 diff --git a/product-planning/references/_留痕/N6-补对齐-20261016/SKILL.md b/product-planning/references/_留痕/N6-补对齐-20261016/SKILL.md new file mode 100644 index 0000000..e9449f4 --- /dev/null +++ b/product-planning/references/_留痕/N6-补对齐-20261016/SKILL.md @@ -0,0 +1,313 @@ +--- +name: product-planning +description: 产品规划总入口（唯一入口），四段式调度：① 产品需求 ② 产品功能 ③ 界面交互 ④ 原型说明文档。四段以 references/stage-* 承载，本文件是总调度与约束。可整段跑也可只调一段。当用户要做产品规划、从零做新产品、只做某一阶段、或不知道从哪开始时调用。 +--- + +# 产品规划总入口 + +> 本 skill 由模型按需自动加载，没有斜杠命令。对话里还没定出对象时，先按「项目与路径约定」定出 `<项目>`；定不出来就停下问用户，不要自行假设。 + +## 用途 + +用户丢来一句模糊想法（例如「我要做一个 AI 短剧分镜画布」）时，本 skill 判断该走哪一段，只做那一段的最小必要工作，产出可交付物，再推进到下一段。 + +本文件管调度与约束。各段怎么做，写在 `references/stage-*` 各自的文件里。 + +## 四段结构（可整段跑，也可只调一段） + +| 段 | 回答的问题 | 子步 | 调用 | 产出物 | +|---|---|---|---|---| +| **① 产品需求** | 要做的东西凭什么成立：什么问题、为谁、为什么值得做 | 1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景 | `stage-discovery` | `docs/pm/<项目>/research/*`。其中 1b 交两种体例：`research/1b-竞品分析.md`（汇总对比）＋ `research/1b-独立分析/<竞品名>.md`（独立分析） | +| **② 产品功能** | 要做哪些功能、什么不做、长成什么骨架 | 2a 产品功能 / 2b 界面布局 | `stage-requirements` | `docs/pm/<项目>/prd/2a-产品功能.md` 与 `docs/pm/<项目>/prd/2b-界面布局.md`（两份） | +| **③ 界面交互** | 长什么样、怎么操作 | 3a 视觉规范 / 3b 原型 / 3c GPT参考版 / 3d 审查打磨 | `stage-delivery` | `designs/<项目>/DESIGN.md`、`designs/<项目>/*.html`、`designs/<项目>/3c-GPT参考版.md` | +| **④ 原型说明文档** | 现有原型怎么用、每条功能落在哪个页面、坏了怎样、怎么核对（文档按七节铺：原型页面地址 → 页面结构 → 功能清单 → 使用场景 → 操作流程 → 页面导航 → 原型状态取值） | 4a 场景盘点 / 4b 说明区 / 4c 演示引导（可选） | `stage-proto-doc` | 原型内嵌说明区 ＋ 独立产品文档 `designs/<项目>/产品文档.html`（两份共用同一套 P 页面／S 场景／F 功能／J 二级功能编号） | + +四段只通过落盘文件耦合。段间交接口如下，这是唯一的契约，越界即失效： + +| 交接 | 由谁给 | 给什么 | 给到哪为止 | +|---|---|---|---| +| ① → ② | ① | 问题定义、需求澄清决策表（含 grill 压测的 B 节：做成什么样 / 哪些情况不成立 / 状态怎么流转）、取证结论（1b 汇总对比体 ＋ 1b 独立分析体、1c 用户画像）、产品定位、《使用场景》＝用户故事（②段功能的直接推导依据） | 功能清单归②段产出，1a 写到需求与形态为止 | +| ② → ③ | ② | 功能清单（每条带优先级 ＋ 状态流转）、界面布局（有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系）、每页主操作、信息承载分档（主屏常驻 / 可点入） | 视觉归③段。骨架必须给全，骨架不给全，③段就一版一个样 | +| ③ → ④ | ③ | 已跑通的单文件原型 HTML（页面、模块、控件、状态、交互、跳转、反馈＝界面事实的唯一依据） | 说明区与独立产品文档归④段；⛔ ④段不重新规划产品、不重新设计界面 | + +> 口径：②段钉骨架，③段做皮肉。两侧逐行对照与用户原话只在②段 `references/stage-requirements/SKILL.md` 的 §②—③ 交接口 定义一次 —— 本入口不复述。要点两条：②段要给全「归②段」列；③段不许增删移动板块，缺板块回②段改。 + +> ②→③ 最容易搞坏。旧病灶：②段说「必须能读到」，③段读成「必须常驻主屏」，五类信息就全铺一屏成了信息墙。分档表把「读到」明确成「一次点击内可达」，防的就是这句歧义。骨架是灰块（有哪些块、什么顺序），③段给的是视觉与交互实现（排版、点哪有什么反馈、空态、响应式）。两件事各管一维，③段不会退化成照抄。 + +> 四段各占一个词，互不共用（2026-10-02 定）：产品 / 功能 / 界面 / 说明。改段名前先对照这张表；两个段名里出现同一个词，边界一定在漂。旧名「调研与方案 / 需求与结构」都含「需求」，③段旧名里的「交付」是三段共有的属性，都属名实不符，已改。 +> 🔴 **④段的沿革（2026-10-14 → 10-15）**：10-14 按用户令删掉**旧版**④段 —— 旧做法是往原型 HTML 注入说明区注解层（状态 → 场景 → 从左到右流程图 → 功能作用/输入边界/异常情况 三段 → 逐步骤演示引导），实测没法用，整段连方法论一并撤掉。10-15 用备份里的**新版**④段装上：改成「解释与记录现有原型」，交**两份产物**（原型内嵌说明区 ＋ 独立产品文档 `designs/<项目>/产品文档.html`），内容先按四块＋附录铺，随后整套同步成**七节**（原型页面地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值），编号改用 P 页面／S 场景／F 功能／J 二级功能，并带一份现成模板 `references/stage-proto-doc/assets/产品文档模板.html`。判据正文在 `references/stage-proto-doc/`，⛔ 旧版那套（状态轴、三段必填、逐步骤演示）不再使用。 +> ①叫「产品需求」不叫「需求调研」：该段产出 `research/1a-需求文档.md`、`1b-竞品分析.md`、`1c-用户画像.md`，也产出 `1d-产品策略.md`、`1e-使用场景.md`，「调研」二字盖不住后半截。 +> ⭐ 1b 是①段唯一交两种体例的子步：独立分析体 `research/1b-独立分析/<竞品名>.md`（竞品池每一个一份），汇总对比体 `research/1b-竞品分析.md`（恒一份）。职责边界与定案原话见 `references/stage-discovery/references/competitor-analysis.md` §0.4。 + +⭐ `grill-me` 全场只有①段一份（2026-10-06 用户定案）：①段那份按 A / B 两节提问，火力点划分、节次归属与定案原话见 `references/stage-discovery/references/grill-me.md` —— ⛔ 本入口不复述。B 节结论落进 `research/1a-需求文档.md`。 + +⭐ ②段产出两份（2026-10-06 收窄，2026-10-07 定为两份）：`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 ＋ 状态流转）与 `docs/pm/<项目>/prd/2b-界面布局.md`（页面关系 ＋ 页面内板块布局）。定案原话与理由见 `references/stage-requirements/SKILL.md` 开头。 + +（交接口反转前的口径、②段收窄前的产出清单与去向 → `references/_留痕/③段与总入口-旧口径.md`） + +⚠️ ①段功能按「使用场景」组织（一条场景可跨多个页面），不按页面组织。 + +段内的子步顺序、方法论文档、硬约束、完成标准，都在各段自己的 `SKILL.md` 与 `references/` 里。 + +①段 1a 需求文档：全程最先做，且只做一次。用 grill-me 与用户互动，产出 `docs/pm/<项目>/research/1a-需求文档.md`（开头写清做什么 / 为谁 / 不做什么，往下是决策表）。 + +## 项目与路径约定（单一真源） + +> 四段全部遵守本节。各段 `SKILL.md` 与 `references/` 里出现 `docs/pm/...` 时，`<项目>` 一律指本节定义的 slug。 + +### `<项目>` 是什么 + +项目 slug 用小写字母、数字、连字符（例 `my-tool`、`video-canvas`）。它就是项目目录这一层的目录名，一个字都不能差，**两个根下同名**。产物**分两个根**落： + +| 根 | 路径 | 装什么 | +|---|---|---| +| 🔴 **文档根** | `docs/pm/<项目>/` | ①段 `research/`（`1a`~`1e`）、②段 `prd/`（`2a-产品功能.md` ／ `2b-界面布局.md`）、跨段 `专题/` | +| 🔴 **设计根** | `designs/<项目>/` | ③段 `DESIGN.md` ＋ 原型 `*.html` ＋ `3c-GPT参考版.md` ＋ 3d 审查留痕件 ＋ 截图 `_gate_shots/`；④段 `产品文档.html` | + +⚠️ **②段 prd 归文档根**，⛔ 不跟③段一起搬 —— 它与①段 `research/` 同根，③段的机检脚本也按 `docs/pm/*/prd/2b-*.md` 去定位它（`find_doc`）。⛔ 已废的那层 `ui/` 子目录不要再写进任何判据。 + +### slug 怎么定（按序取第一个成立的） + +| 序 | 条件 | 取值 | +|---|---|---| +| 1 | 用户在当前会话里明确说了项目名 | 该名字 slug 化 | +| 2 | `.registry/current-project` 存在且非空 | 其内容 | +| 3 | `docs/pm/` 下恰有一个非 `_` 开头的目录 | 该目录名 | +| 4 | 以上都不成立 | 停下问用户 | + +写任何文件之前先核对：目标路径里的 `<项目>` 段与按上表得出的 slug 是否一致。不一致就停下说明，不要「先写了再说」——猜错会把产物写进别的项目，事后极难拆干净。 + +### 产物落哪 + +| 段 | 路径 | +|---|---| +| ① 产品需求 | `docs/pm/<项目>/research/` | +| ② | `docs/pm/<项目>/prd/` | +| ③ | `designs/<项目>/DESIGN.md`、`designs/<项目>/*.html`、`designs/<项目>/3c-GPT参考版.md` | +| ④ | 原型内嵌说明区（写进 `designs/<项目>/*.html` 自身）＋ 独立产品文档 `designs/<项目>/产品文档.html` | + +### 文档的两态：当前版与过期版 + +用户令（2026-10-11 逐字）：「**应该有文件夹 专门归档过期文档， 当前文档 统一放在方案文件夹中**」。 + +🔴 **方案文件夹** ＝ `docs/pm/<项目>/` 这一层 —— 它下面放的全是**当前权威版**：①段 `research/`、②段 `prd/`、跨段 `专题/`，另加一份 `索引-当前权威版.md` 当入口。 + ⚠️ ③段与④段的产物**不在**文档根 —— 它们在设计根 `designs/<项目>/`（见上「产物落哪」）。⛔ 别按老口径去文档根下的 `ui/` 子目录找原型（那层已废，原型在设计根顶层与 `DESIGN.md` 同处）。 +🔴 **归档文件夹** ＝ `docs/pm/<项目>/归档-过期版/` —— 被顶替下来的旧版全放这里，命名 `<原名>__<来源目标短哈希>.<扩展名>`（例 `2b-界面布局-新版__fc471a.md`）。 + +**每个目标收口时做四步**： +1、本目标的权威文档**覆盖**方案文件夹里对应的那一份。 +2、被顶替的旧版**移进** `归档-过期版/`，按上面的命名补上来源短哈希。 +3、更新 `索引-当前权威版.md` 里对应行的大小与日期。 +4、执行区（`执行会话/目标-*/` 这类过程目录）里的原件**保留** —— 它既是过程留痕，也是台账 `artifact` 指向的地方，搬空会让回查断链。 + +**为什么要有这条**（避坑依据 · 2026-10-11 实测）：同一个 `2a-产品功能` 在 6 个目标目录里各有版本、`2b` 有 7 个，光看文件名与字节数分不出谁新；而 `docs/pm/` 下早先那次归档又停在旧版（`2b` 只 52 256 B，最新已是 52 643 B）⇒ 用户问「很多新老方案都在文件夹中，后续根据方案细化产品界面，如何找得到对应的方案」。判断某份文档的当前版，**只看方案文件夹**；问「当时为什么这么定」才去归档文件夹翻。 + +### DESIGN.md 为什么在项目目录、不在仓库根 + +`DESIGN.md` 是③段的绑定视觉规范，一个项目一份，③段按当前项目的 slug 去读它。仓库根只能放一份，多项目会互相覆盖，所以一律放 `designs/<项目>/DESIGN.md`（与原型同目录）。 + +推论（硬规则）：读 `DESIGN.md` 时，路径必须由本节定义的 `<项目>` slug 拼出，不许用「当前工作目录碰巧有 DESIGN.md」这类推断。仓库根不放任何项目的 `DESIGN.md`。 + +## 工具选择规则（防止选错，最重要的一节） + +> 下表是选型总则。这些工具都已封装在对应段内，本文件只负责让你不选错；具体调用路径见各段 `SKILL.md`。 + +| 要什么 | 用谁 | 别用 | +|---|---|---| +| 页面设计全链（规范 → 原型 → 审查） | ③段 `stage-delivery` 自己的 D0→D5 流水线 | 另找风格库，或自己手搓一套 token 与门禁 | +| 评审用的可点原型 / 生产级前端页面 | ③段 3b（按 D2 构建，单文件 HTML 交付）。先判页型：营销页取③段 §供给·版式骨架 的可选档，工具型页面取其默认档 | 不判页型就套可选档种子——那是营销落地页骨架，会把后台做成营销页 | +| 设计规范文件 | ③段 3a 生成 `DESIGN.md`（令牌表取自③段选定套，见③段 §供给·定调与令牌；再加该项目②段的界面需求） | 凭空编一套 token | +| 架构图 / 流程图 / 时序图 | `diagram-design` | 手写 Mermaid | +| 状态迁移的守卫、副作用、并发 | `state-machine` | 指望 diagram-design 覆盖这些 | +| 审美方向 / 风格定调 | ③段 §供给·定调与令牌 的默认档里选一套（可选档亦见该处），读候选套按页面类型挑。⛔ 每次只选一套 | 「米白＋衬线＋陶土色」这类默认审美，或凭感觉编 | +| 多方向比选 / 独立评审打分 | ③段 §供给·多方向比选 与 §供给·独立评审协议 | 拿它的评分循环替代本段 Gate-1/2/3 | + +③段的页面设计供给 —— 默认主线、定调与令牌、版式骨架、工艺数值判据、独立评审协议、多方向比选，共六档；各档的默认来源 / 可选来源 / 路径只在③段 `references/stage-delivery/SKILL.md` 的 §供给 定义一次，本入口不复述，要改供给只改那一块（2026-10-08 起）。`oil-ui-pro` 是界面设计方法论：五步流程（探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付），加风格对比页与截图工具；它自带联网版本检查与自动更新，是用户明确要求全量搬入的例外项（既有纪律是「依赖外部服务一律不收」），已记录在案，不扩散。 + +默认走 `oil-ui-pro` 主线，不与可选档缝成一条流水线：可选档只在 §供给 里列，选了才作补强（多一路定调候选、多一套工艺数值判据），不选也不影响开工。 + +四样东西供给件里都没有对应，由 `stage-delivery` 自己扛：设计契约十二字段、结构骨架、交互清单、工具型版式库。 + +页型分流（2026-10-05 新增）：③段 §供给·版式骨架 的可选档是营销落地页向，工具型页面照它做会长出「标题上下各一行小字」的三段式（骨架名单与理由见③段 `references/stage-delivery/references/layouts-tooling.md` 开头）。本项目实测踩过这个坑，结构判据全绿也拦不住。所以③段 D0 必须先判页型，工具型页面版式一律走 §供给·版式骨架 的默认档。 + +只读一处来源：同一条判据若在默认档与可选档各有一份且口径不同，以本项目追加条为准 —— ⛔ 但追加条不得放宽基础层（`oil-ui-pro` 是基础层、其余是叠加层，分层规则见③段 §供给），并在 runbook §3.4 显式标注「本项目追加」。 + +DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec` 四个子命令，目前是 alpha（v0.4.0）。非 TTY 的管道里可能不回显输出，需在真实终端里确认。本机实测该命令完全不可用，不要拿它当校验关卡；改由 D3 收口与 D5 终检按真实像素人工复测对比度（判据见③段 §供给·工艺数值判据 里配色那一份）。原两把门禁脚本（静态文案检查 / 渲染机检）已随旧主干从磁盘移除，当前没有机器复现，结论只能记「人工判定」，不得写成「脚本已通过」。 + +## 可调用工具（自然语言触发） + +> 两个独立工具，按用户说法直接触发，产物落项目目录。`design-capture` 随③段携带（装在③段 `references/stage-delivery/assets/` 下）；`video-capture` 2026-10-11 已独立成全局技能（装在**技能根**下的 `video-capture/`），跨段复用。两者都不单独成段。 + +| 用户说 | 触发工具 | 做什么 | 产物 | +|---|---|---|---| +| 「分析 XXX 视频」「把这个视频抽帧」「拆一下这条视频的画面」 | 全局技能 `video-capture` | 取视频（本地文件 / 直链 URL / 平台页经浏览器下到本地）＋ 抽帧（双因素 ＋ 首尾 ＋ 补帧） | 关键帧 `c_<序号>_<真实秒数>s.jpg` ＋ `frame_times.json`（供①竞品分析、③视觉参考） | +| 「获取 XXX 网站的设计风格」「抓这个网站的风格/组件/配色」 | `stage-delivery/assets/design-capture/` | 抓网页设计系统（色彩 / 排版 / 组件），生成样式模板 | 一套 `design-system-<名>/`（与 `design-system-tiaoyue` 同构，可直接被③段 D1 选用） | + +两者都独立可单跑：`video-capture` 只依赖 `ffmpeg`（权威件＝全局技能 `video-capture`；原 `stage-delivery/assets/video-capture/` 只留交接说明，脚本迁至 `references/_留痕/video-capture-已独立-20261011/` 留档）；`design-capture` 只依赖本机 Chrome（CDP）＋ `vendor/` 里搬运的抽取脚本，不需要任何外部服务在场。用法与边界见各自 `SKILL.md`，来源与署名见各自 `ATTRIBUTION.md`。 + +触发时机：①②段拆竞品视频用全局技能 `video-capture`；③段要新建样式或拆参考站用 `design-capture`。 + +两个工具都只做合规最小集：不抓平台页内视频，不调付费接口；抽取结果须先目视比对再采用。 + +## 进入方式 + +| 你说什么 | 模式 | 从哪开始 | +|---|---|---| +| 「规划 XX」「从零做 XX」 | 全流程（自动处理） | `stage-discovery` → `stage-requirements` → `stage-delivery` → `stage-proto-doc`，一路跑完，段间不停下来问（含①段末） | +| 「先确认方案」「跑完方案停下等我」「规划 XX，先给方案」 | 方案确认 | 同一套四段，唯一差别是①段末停下等你确认方案，确认后才进②③④ | +| 「只做产品需求」「只做产品功能」「只做界面交互」「只做原型说明文档」 | 单段 | 只调对应那一个 stage skill，不展开其他段 | +| 已有②段，要出原型 | 单段 | 直接调 `stage-delivery`，从它的 3a 起 | +| 已有原型，要补说明 | 单段 | 直接调 `stage-proto-doc`，从它的 4a 起 | +| 只问某个单点 | 单段 | 不跑任何段，在对应 stage skill 内点名子步，或直接说要看哪份方法论 | + +「只调一段」成立的原因：四段之间只通过落盘文件耦合，没有隐式状态。 + +- ②只读 `docs/pm/<项目>/research/*`；缺失时标注 `【假设】`继续，不催促回补① +- ③只读 `docs/pm/<项目>/prd/*`；缺失时同样标 `【假设】`继续 +- ④只读 `designs/<项目>/*.html`（界面事实的唯一依据），另按需读 `docs/pm/<项目>/prd/*` 与 `research/1a-需求文档.md` 定业务意图；缺失时标 `【假设】`继续，并在段末偏离单里写明 + +## 执行规则 + +只有三种模式，没有第四种： + +| 模式 | 段之间 | 段之内 | +|---|---|---| +| 全流程（自动处理） | 一路跑完，段间不停下来问（含①段末）。每段结束按「标准收尾格式」输出一段报告，输出完即刻进下一段 | 子步之间不反问，做完直接进下一个子步 | +| 方案确认 | 与全流程完全相同，只有一处不同：①段末停下等你确认方案；确认后②③④一路跑完、段间不停 | 同上 | +| 单段 | 不涉及 | 不越界，不催促回补前段 | + +这两条是全流程模式下的两个独立分支，不要混：全流程（自动处理）没有①段末的强制停；「停下等确认方案」只在「方案确认」模式下发生。二选一由用户定（界面里点【生成原型和文档】时选「自动处理」或「先确认方案」，或在会话里直接说明）；用户没明说时按自动处理走，不要在自动处理模式下自作主张停下来问。 + +「停下」指什么，不要读成「每一步都要反问用户」。只有这四种情况才停： + +1. 信息不足且查不到，必须用户给（如「项目与路径约定」slug 第 4 条）——停下问 +2. 破坏性 / 不可逆动作——二次确认 +3. 用户显式要求某个子步做完停下 +4. ①段末的方案确认（仅「方案确认」模式）——把方案摆给用户：做什么 / 不做什么 / MVP 边界 / 未复核的 `【假设】`，明说「等你确认方案，确认前不进②段」 + +段末报告：全流程（自动处理）模式下，所有段（含①）都只输出报告，不提问、不等回答；方案确认模式下①段是唯一例外，其余段同样只输出报告。 + +①段末的确认是回环，不是一次问答（仅「方案确认」模式）：用户看到方案后可以提问题要求改，可能多轮，每轮的「问题＋怎么改的」都要留痕、不得覆盖上一轮；改完由用户显式说「确认方案」才算过闸门。该模式下，没拿到用户确认的方案不得当成既定事实带进②段——这是实测踩过的坑：②段拿着未经确认的方案往下跑，把用户已拍板的需求裁掉了。 + +其余规则： + +- 声明制（全段适用，不止③段）：开工前、每进一个子段或子步、每处偏离，都要声明三件事——当前在哪、依据哪个文件的哪一节、产出落哪；偏离当场写明原因与影响，段末附偏离单。不许静默偏离。实测踩过的坑：③段 3b 交付了原型却没走当时声明的主流程、没读依据文件，也没当场说，用户追问「基于哪个 skill」才知道。 +- 不做八股：不介绍方法论来源，不列人名，不复述框架历史，直接给结论。 +- ⭐ 内容准则：一切落盘文字都要先过「说人话」这一关（2026-10-07 用户定案，同日扩大到规则文件）。用户原话：「当作第一步 和 第二步 生成文档时 必须遵循的内容准则」「不管是写规则 还是 写文档 都要严格按照说人话的技能去执行」。 + - 适用面两类都算，只改产出不改规则等于半改。一是产出文档：`research/1a-需求文档.md` 到 `1e-使用场景.md`（5 份）、`research/1b-独立分析/`（独立分析体）、`docs/pm/<项目>/prd/2a-产品功能.md` 与 `docs/pm/<项目>/prd/2b-界面布局.md`（2 份）。二是规则本身：本技能包内的一切落盘文字，`SKILL.md`、`references/**`、模板与清单。 + - 判据来源（单一可信源，本文件不复述模式清单）：**只有 `humanizer` 一份，且只用它的英文正式目录** —— `<技能根>/humanizer/references/patterns.md` 的 **P1–P55**（内容 8／语言与风格 10／沟通 3／填充与模糊 9／新兴 13／工艺与取证 12）。另有 5 种口吻档（casual / professional / technical / warm / blunt）。 + - 🔴 **判据一律用英文目录（2026-10-15 用户令）**：中文附录 `patterns.zh.md`（ZH1–ZH15）**只作参考线索，⛔ 不作判据** —— 作者自标「实验性、未经中文母语写手校验、不应被当作已验证的规则」。原中文版 `humanizer-zh` 的 24 条与五维 50 分表随该技能删除一并停用作废。 + - 门槛（2026-10-15 改）： + · **英文产出**：可读 `--score` 的 0–100 AI 痕迹密度分（越低越像人；上游 pre-commit 的拦截线是 40），本包不设硬阈值，分数写进段末报告。 + · **中文产出**：⛔ 不采信自动分数 —— 该打分器按 `[.!?]` 切句、按 `[a-z0-9]` 切词，中文 `。！？` 不切句、汉字零词，分数实际在测「文件里有多少拉丁字符」（实测：同一段中文把 `。` 换成 `. ` 分数不变；零拉丁字符的中文直接判 `No text`）。改按 **P1–P55 逐条人工对照**，再跑 `--check-facts` 保真（它只抽数字／日期／版本／URL／路径／标识符，中文同形可用）。对照结果与事实存活数写进段末报告，命中项不对完不许落盘。 + - ⛔ 取不到判据来源时（2026-10-08 补）：两份技能都不在位或读不到 ⇒ **不许凭感觉判「这条够人话」**。在段末报告与 3d 审查留痕件（`3d-审查报告.md` 或 `DESIGN.md` 审查节）里明写「无判据来源，本项未判」，按与 §供给·工艺数值判据 的「证据缺口」同一口径处理。 + - 五条核心原则（2026-10-15 起**就地固化在本包**；原引自已删除的 `humanizer-zh`《核心规则速查》，英文版 `humanizer` 的 Quick reference 没有等价条目，故不再指向外部）：删填充短语（开场白、强调性拐杖词）；打破公式结构（二元对比、戏剧性分段、修辞性设置）；变化节奏（长短交错，两项优于三项，段尾多样）；信任读者（直接陈述事实，跳过软化、辩解、手把手引导）；删金句（读起来像可引用的话，就重写它）。 + - 🔴 **适用面要划清（2026-10-15 排查后立）**：本包只取这份技能里**「去 AI 味」那一半**，⛔ 不取**「注入个性」那一半**。 + 取这些：英文模式目录 `references/patterns.md` 的 P1–P55、就地固化的五条核心原则、禁用清单。 + 不取这些：`Soul Injection Techniques` 整节（11 条）—— 它明写「有观点、别只报告事实」「用具体感官／体验细节代替抽象说法」「允许跑题与题外话」「结尾不必收束」「用 imperfect start 开场」，与本包产出要的**客观书面说明文**正好相反（照它写会出乱比喻、口水话、不能简明扼要）。该节第 3 条自带的示例就是「凌晨两点冷咖啡和看不懂的堆栈」这种感官化写法。 + 口吻档：本包产出**固定取 `technical`**（精确用词、一句一个意思、⛔ 无比喻除非确能澄清），⛔ 不用 casual／warm／blunt。 + ⛔ **已停用**：原中文版 `humanizer-zh` 及其五维 50 分表（该技能 2026-10-15 已整包删除，判据不再走它）。 + - 🔴 **同一件事更严的那份说了算**：④段的 `references/doc-language-spec.md`（客观书面说明文 ＋ 逐条禁用清单）是本包最严的一份语体规范；任一段落盘文字与它冲突，**以它为准**。 + - 交付留证：产出文档在段末报告里写明「已过内容准则，评分 X/50」；改规则文件时，在当日 memory 里记下这一关过了。 +- 只调一段时不越界：用户说「只做第 N 段」，就跑该段，不展开其他段，也不用「你还没做调研」去催促。 +- 提问上限 3 个：其余用合理假设，并在文档里标注 `【假设】`。例外是 `grill-me` 提问模式，不受此限（①段的「需求澄清」与②段的「需求压测」各一次），该模式的价值就是穷尽提问；此时须先声明「将连续多轮提问」，退出后恢复本约束。 +- 反问优先，允许自动补全：`grill-me` 的默认动作是把问题抛给用户并附推荐答案。用户说「你定」、连续两轮不回应、或属事实类问题时，模型自行给答案并标 `【假设】`，换来「不卡住」；但每轮结束要汇出待复核清单，未经复核的 `【假设】` 不得在下游当事实用。 +- 停线规则（**单一真源，全包只在本节写一次**，各段一律引用、⛔ 不复述）：只有三种情况停 —— ① 信息不足且查不到；② 破坏性／不可逆动作；③ 用户显式要求。 +- MVP 边界优先：任何阶段都先回答「第一版做什么、不做什么」。 +- 必须落盘：产出写入文件，不要只在对话里输出。 +- 无来源就标注：任何查不到来源的数据都标为「估算」并写明口径，不编造数字当事实。 +- 禁止长文：单份产出物默认一页纸（≤120 行），超长必须拆分。 +- ⭐ 落盘产出的排版（2026-10-14 用户令，原话「标题周围写小字的怪毛病 彻底改掉」）：元信息（条数、口径、读法、状态）写进表格的列、条目的字段或表头；标题旁边、标题下面、标题后面都只放标题本身。④段的 `references/doc-language-spec.md` 另有一份更细的，冲突以那份为准。 +- 🔴 路径写相对或占位（2026-10-14 用户令）：本包内一切文字（`SKILL.md`、`references/**`、脚本与注释、模板）引用**本技能自己或同根技能**的位置时，写相对形态 —— 同根技能写 `<技能根>/<技能名>/`，本包自己的文件写包内相对路径（如 `references/stage-delivery/`）。只有**跨根引用**（工作区根、文档库根、本机软件安装位这类从本包推不出来的别的根）才落到具体位置，且优先读环境变量（`DSH_WS_ROOT` / `DSH_DOCS_ROOT` / `WORKBUDDY_BIN_ROOT`）。原因：技能根的位置随环境变（全局技能根还是工作区技能根、用户名与盘符各不相同），写死了换台机器就是死路径，跨环境会整片报错。 + +## 征询外部模型（GPT）的提问口径（单一真源） + +> 🔴 2026-10-15 用户令，逐字：「问 GPT 的时候 只需要说明 关键背景情况和需求询问，禁止带入过多细节上下问造成干扰」。本包内一切向外提问的动作都按本节写；③段 3c 的提问模板是本节的一个实例，⛔ 不在别处另立一套口径。 + +- **要写三样**：① 场景一句（这是什么、要解决什么）；② 手上已有什么（只列与本次提问有关的）；③ 想问哪几个问题（逐条列，一条一个问点，末尾一句收口）。 +- **判据**：背景写到「对方能接住这个问题」为止 —— 少了这句，对方就问不出对的问题吗？问不出才留，问得出就删。 +- **⛔ 不带**：过程留痕、已废弃做法的设计细节、「我们为什么这么做」的来龙去脉、内部硬约束清单、字段与文件清单。这些会把回答拖进细节纠缠，占掉本该用在核心问题上的注意力。 +- **为什么**（避坑依据 · 2026-10-14 实测）：为问「原型说明文档该怎么写」，先铺了 1 500 余字的背景（含已废弃做法的 5 个设计点、4 条硬约束、7 个问题）⇒ 细节量压过问题本身。 +- **留痕**：提问原文与回答原文都要落盘；提问按本节写，⛔ 不把本机路径当内容（外部模型看不到本机路径，要么逐字内联、要么上传文件）。 + +## 产出文档开头必须有图（单一真源） + +> 2026-10-15 用户令，逐字：「产品规划页面 所有文档前面都要画图」。各段一律引用本节，⛔ 不在段内另写一套口径。 + +- 每份落盘文档**第一屏就给一张图**：图放在标题之后、正文之前 —— 不读正文也能先拿到全貌。 +- 图是**正文内容**，⛔ 不写成标题旁边或标题下面的注解小字（与上面那条排版红线同一件事）。 +- 图要**表达结构或流程**（二选一或兼具）—— 一张图看完就知道「由哪几块组成、怎么连起来」或「一件事分几步走」；⛔ 不做纯装饰性配图。 +- 图表达这份文档**覆盖的东西之间的关系**，按段定画什么： + · ①段（`research/` 五份）—— 画对象与流向：为谁解决什么、信息从哪来到哪去。 + · ②段（文档根 `docs/pm/<项目>/prd/` 两份）—— 画页面骨架：有哪几页、每页几个板块、跨页关系怎么走。 + · ③段（`ui/` 下的产物与 `DESIGN.md`）—— 画页面结构与操作动线：用户办成一件事实际经过哪几页、每页做什么、哪里要来回跳。 + · ④段（产品文档）—— 画页面结构图（各页面与其下的功能编号）＋ 用户路径：各场景怎么串起来。 +- 画图用 `diagram-design`，⛔ 不手写 Mermaid（判据见「工具选择规则」那张表）。 +- 图里每格写清名字、线标方向；图与正文互相对得上 —— 正文新增或改了结构，图要跟着改，两处不许各说各的。 + +## 每段的标准收尾格式 + +``` +## 本段结论 +- （3-5 条，可直接决策的话） + +## 已落盘 +- ... + +## 待确认（最多 3 条） + +## 建议下一步 +→ 用 完成 <具体事> +``` + +## 反面清单 + +- 为一个小功能跑完整调研 +- 输出长文却给不出一个结论 +- 跳过「不做什么」 +- 用户只问单点，却强行拉进全链路 +- 把估算数据写成确凿事实 +- 跳过③段 D0 的 Gate-1（未定死令牌表与设计契约）就开写页面代码 +- 在 `grill-me` 提问模式下仍套用「提问上限 3 个」，把提问做成走过场 +- 只跑一次 `grill-me`：①没定义需求就去取证，或②拿①段的需求定义代替功能压测直接写②段 +- 把自动补全当默认动作：用户没说话就替用户拍板，还没标 `【假设】`、没进待复核清单 +- 手写 Mermaid 代替 diagram-design，手写 token 表代替 DESIGN.md +- 绕过四段自己手搓，或重写它们的内容（该调 `stage-*` 就调） +- 把供给件的内部路径按本 skill 目录去拼，或改它们的正文 —— 供给件指③段自带的 `oil-ui-pro`，以及 §供给 各档落在 `assets/` 下的件（它们是随③段携带的供给件，改动只写 `stage-delivery` 自己的 `SKILL.md` / `references/`；默认档与可选档平行，不缝成一条流水线，也不把 `oil-ui-pro` 的评分循环当成本段 Gate 的替代） +- 猜 `<项目>`：定不出来还硬写，把产物落到别的项目目录下 +- 把 `DESIGN.md` 写到仓库根：多项目会互相覆盖 +- 段间停下来问「要不要继续」：全流程（自动处理）模式下直接进下一段，只在段末输出报告 +- 把两种模式混用：在自动处理模式下自作主张停下问方案，或在「方案确认」模式下确认前就开跑②③④ +- 在「方案确认」模式下把①段的方案当成已确认就往下跑：该模式下①段末必须停下等用户确认（含「不做什么」） +- 下游擅自裁剪上游已拍板项：②③④发现要砍①段或决策表里已拍板的东西时，不许自行裁掉或改口径，必须列成「与已定决策的差异」交用户显式确认 +- 把模式当成段：模式是「要不要在①段末停」的开关，不是第五个段，别为它单独造段或造产物 +- 跑了却不说：没声明当前段 / 子步与依据文件，或偏离了被调 skill 的主流程却不声明、不记偏离单（应为：开工先声明、每个子步再声明、偏离当场声明） +- 让③段顺手把说明区或产品文档写了（那是第④段 `stage-proto-doc` 的活） +- ④段里重新规划产品、重新设计界面，或写原型上没有的页面 / 功能 / 业务规则（④段只解释与记录**现有**原型） +- 问外部模型时堆砌背景：把过程留痕、废弃做法、内部约束清单整段贴进去（应按「征询外部模型（GPT）的提问口径」只给关键背景 ＋ 明确问题） +- 落盘文档开头不给图，或图与正文各说各的（应按「产出文档开头必须有图」先上图、再写正文，两处对得上） +- 过「说人话」时把「注入个性」那半也照做：加观点、加第一人称、写感官细节与比喻、允许跑题（应按内容准则只取「去 AI 味」那半，产出仍是客观书面说明文） + +## 改名 / 改供给后的自检 + +```bash +python scripts/check_naming.py --ws <工作区> +``` + +它查四段段名与子步名在「总入口 ↔ 各段 `SKILL.md` ↔ 各段 `references/`」之间有没有漂，包括 H1 与子步表是否一致、总入口子步列有没有漏项、runbook 必读表有没有引用已移除的资产、两份副本是否一致。纯静态比对，不需要渲染，不需要外部依赖。 + +为什么必须有它：实测当天漏过两次，当时没有任何门禁会报错。 + +第一次（2026-10-02）：改段名时 `SKILL.md` 改了，但 `references/stage-discovery/references/grill-me.md` 的 H1 仍写「需求澄清（grill-me · 调研段）」；`references/stage-requirements/SKILL.md` 子步表写「2b 功能流转」而正文 H2 写「## 2b 状态机」；总入口④段子步列只写「4a 说明区 / 演示引导」漏了 4b / 4c。三处都只能靠回读发现。 + +第二次（2026-10-06）：②段收窄为「只细化功能」（7 份产出变 1 份）后，各段 `SKILL.md` 都改了，但总入口的三处仍写着旧结构——四段表的②段子步列仍是「2a 功能定义与压测 / 2b 功能流转 / 2c 功能图示」，四段表的①段子步列「1c 产品定位与商业设计」未随段内改名（段内已改称「产品定位与场景」），正文仍写「①与②各跑一次 `grill-me`」并指向两份同名文档，实际全场只有①段一份。闸门当场报 6 个 FAIL，根因是「改了承载段、忘了总入口」。 + +由此立一条硬纪律，与「换供给不能只改承载段」同型：凡改子步结构 / 段内产出清单 / 段间交接口，必须连带改总入口 `product-planning/SKILL.md` 的「四段结构」表与「交接口」表，不改就是半改状态。 + +改了段名 / 子步名 / 判据供给源之后必须跑一次，并把结果记进当日 memory。改完不校验，下次读契约的人拿到的是错的配方。 + +本脚本只查文本一致性（H1 ↔ 子步表 ↔ 总入口 ↔ 副本），查不出「判据口径是否自相矛盾」。例如「②段到底该不该给页面结构」这种反转，闸门一个字都报不出来。口径类改动要靠人工回读，且必须把反转理由与用户原话写进文档留痕。 + +脚本输出里的 `[提示]` 项（旧名出现）不计入失败，但要人工看一眼是不是落在「废止理由块」里——落在里面是正当留痕，散落在正文里就是真残留。 + +2026-10-07 起本技能只在全局一份：技能根下的 `product-planning/`。它就是本体，不再有「主 / 副 / 装入」三副本，也不再需要「三处 md5 复核」（那只在有副本时才有意义）。改完只跑一次 `check_naming.py --ws <工作区>`。用户原话：「把产品规划复制到 workbuddy 全局skills中 后续维护和使用全局技能」。工作区原先那三份已归档到 `归档/技能迁全局-20261007/`（未直删，可随时取回）。 diff --git a/product-planning/references/_留痕/N6-补对齐-20261016/_crlf-baseline-D1.json b/product-planning/references/_留痕/N6-补对齐-20261016/_crlf-baseline-D1.json new file mode 100644 index 0000000..5a1c823 --- /dev/null +++ b/product-planning/references/_留痕/N6-补对齐-20261016/_crlf-baseline-D1.json @@ -0,0 +1,26 @@ +{ + "SKILL.md": { + "crlf": 0, + "lf": 313, + "occ_old": 4, + "occ_tpl": 1 + }, + "references/stage-discovery/SKILL.md": { + "crlf": 0, + "lf": 232, + "occ_old": 1, + "occ_tpl": 0 + }, + "references/stage-proto-doc/SKILL.md": { + "crlf": 0, + "lf": 186, + "occ_old": 1, + "occ_tpl": 7 + }, + "references/stage-requirements/assets/产品规划模板.md": { + "crlf": 0, + "lf": 58, + "occ_old": 1, + "occ_tpl": 0 + } +} \ No newline at end of file diff --git a/product-planning/references/_留痕/N6-补对齐-20261016/references/stage-discovery/SKILL.md b/product-planning/references/_留痕/N6-补对齐-20261016/references/stage-discovery/SKILL.md new file mode 100644 index 0000000..80faea0 --- /dev/null +++ b/product-planning/references/_留痕/N6-补对齐-20261016/references/stage-discovery/SKILL.md @@ -0,0 +1,232 @@ +--- +name: stage-discovery +description: 产品规划第①段，产品需求。五个子步依次产出五份文档：1a 需求文档（用 grill-me 反问澄清需求，用户不答时给推荐答案并标【假设】继续）、1b 竞品分析、1c 用户画像、1d 产品策略、1e 使用场景（按用户故事格式写：谁、在什么处境下、要办成什么）。当用户要做竞品分析、用户画像、产品策略、使用场景，或说"只做产品需求"时调用。 +--- + +# ① 产品需求 + +回答"做什么、为谁、为什么值得做"。产出只有五份，全部落 `docs/pm/<项目>/research/`。 + +> 段名定为「产品需求」（2026-10-02 定）：本段 1b 做调研，1d/1e 定产品策略与场景，"调研"盖不住后半截，还会让②段的"需求"二字失去归属。四段各占一个词：产品 / 功能 / 界面 / 说明。 + +## ⭐⭐ 产出白名单（2026-10-06 用户定案 · 硬规矩） + +本段在 `research/` 顶层只产出这五份，一份不多、一份不少： + +| 子步 | 产出 | +|---|---| +| 1a 需求文档 | `research/1a-需求文档.md` | +| 1b 竞品分析 | `research/1b-竞品分析.md`（汇总对比体，恒一份）＋ `research/1b-独立分析/<竞品名>.md`（独立分析体，竞品池里每一个一份） | +| 1c 用户画像 | `research/1c-用户画像.md` | +| 1d 产品策略 | `research/1d-产品策略.md` | +| 1e 使用场景 | `research/1e-使用场景.md` | + +🔴 用户原话：「禁止出现之前确定的以外的文档，除非用户明确要求」。 +不许自行新增第 6 份。实测栽过：某轮因为"用户点名了参考产品"就自作主张多产了一份《参考实装拆解》，用户反复看到"冒出来的不相关的文档"。"参考产品怎么做的"属 1b 竞品分析的取材范围，写进本份里，不另立一份。 +⭐ `1b-独立分析/` 子目录不算"第 6 份"：它是 1b 的既定体例之一（定案原话见 `references/competitor-analysis.md` §0.4）。它的份数由竞品池决定，不由人临时加。除此之外仍只许上面那五份。 +✅ 门禁可查：`check_naming.py` 扫 `research/` 顶层的实际文件名，出现白名单外的文件名即报红（子目录天然放行）。 + +## 本段职责（2026-10-06 重划） + +本段回答一个问题：要做的东西，凭什么成立。拆成五问，各对应一个子步： + +| 问 | 子步 | 产出 | 性质 | +|---|---|---|---| +| 要解决什么问题、边界在哪 | 1a 需求文档 | `1a-需求文档.md` | 拍板 | +| 别人做了什么、我们差在哪 | 1b 竞品分析 | `1b-竞品分析.md` ＋ `1b-独立分析/` | 外部取证 | +| 用户是谁、他要办成什么事 | 1c 用户画像 | `1c-用户画像.md` | 外部取证 | +| 为什么值得做、边界与风险 | 1d 产品策略 | `1d-产品策略.md` | 判断 | +| 用户怎么用它 | 1e 使用场景 | `1e-使用场景.md` | 判断 | + +> ⭐ 1b/1c 是本段的证据地基，1a/1d/1e 的每条结论都要能追回它。没有外部取证，1d 就是凭想象定战略——实测踩过：三个 JTBD 全是同一个人的三种时刻，零外部取证。 +> 1a 与②段的 2a 是两件不同的事，见文末「需求文档在本段的落点」。 + +顺序 1a → 1b → 1c → 1d → 1e。需求没澄清就不许开取证，没有事实依据就不要定策略。 + +> 下面表格「读」列是该子步的方法论文档，路径相对本 skill 目录。执行某个子步前先读它。 + +## 1a 需求文档（必做，最先） + +| 子步 | 读 | 产出 | +|---|---|---| +| 需求文档（grill-me） | `references/grill-me.md` | `docs/pm/<项目>/research/1a-需求文档.md` | + +🔴 本子步的产出是「一份」文档（2026-10-06 用户定案）：`1a-需求文档.md` 一份说清全部。开头写清"做什么 / 为谁 / 不做什么"，往下摊开成决策表：目标、用户、范围与"明确不做什么"、手上已有的素材、约束、依赖、替代方案。 +（历史：为什么从两份并成一份 → `_留痕/①段-已删除产出与方法论.md`） + +默认反问用户，附推荐答案。用户说"你定"、连续两轮不回应、或问题属事实类时，模型自行补答案并标 `【假设】`，但每轮结束要汇出待复核清单让用户一次性过。未经复核的 `【假设】` 不得在 1d 当事实用。 + +本子步不受"提问上限 3 个"约束，把需求问清楚正是它的全部价值。进入前先声明"接下来会连续多轮提问"。这是本段唯一例外（详见 `references/grill-me.md`）。 + +⭐ `grill-me` 全场只有本段这一份（2026-10-06 用户定案，原话见 `references/grill-me.md` 开头）。本份按 A / B 两节提问，火力点划分与节次归属见 `references/grill-me.md` —— ⛔ 本文件不复述。 + +> 不许再加回②段一份。②段从 2026-10-06 起只细化功能，不再反问需求，反问在这里一次性做完。 +> ⚠️ 合并的代价要说清：两个火力点合到一处，提问量必然变大。用"分节提问"解决，不许因为量大就省略 B 节——跳了 B 节等于把功能压测整个删掉。 +> ⭐ B 节只给粗粒度形态（有哪几页、大概几个板块），不把页面结构写死（精确板块清单与布局归②段的《界面布局》）。 + +## 1b 竞品分析（外部取证） + +| 子步 | 读 | 产出 | +|---|---|---| +| 竞品拆解 · 独立分析 | `references/competitor-analysis.md` §11 | `docs/pm/<项目>/research/1b-独立分析/<竞品名>.md`（竞品池里每一个一份） | +| 竞品拆解 · 汇总对比 | `references/competitor-analysis.md` §1—§10 | `docs/pm/<项目>/research/1b-竞品分析.md`（恒一份） | + +1b 交两种体例。职责边界、份数与定案原话见 `references/competitor-analysis.md` §0.4 —— ⛔ 本文件不复述。只交一种 ⇒ 1b 没做完。 + +> 🔴 写作口径（2026-10-07 补 · 用户报障逐字：「生成的文档并没有说人话，还是我手动要求的」） +> 本段产出是给人看的文档，不是模型味的总结。落笔前读一遍 `product-planning` 的「执行规则 · 内容准则」那一条 —— 判据**一律用英文模式目录 P1–P55**（`humanizer` 的 `references/patterns.md`），中文附录只作参考线索；⛔ 不再引用 `humanizer-zh`（该技能 2026-10-15 已删除）。 +> 定稿前按那条的清单过一遍。 +> 高频 AI 味一律禁：三段式排比连用、空转评价（「具有重要意义」「值得关注」）、以「…着」结尾的肤浅分析、模糊归因（「业内人士认为」）、过度加粗、把一句话拆成内联标题垂直列表。 +> ⚠️ 这条口径适用于本段全部五份产出（1a～1e），不只 1b。 + +⭐ 用户点名的"参考实装"写进本份，不另立文档（见「产出白名单」）。它是竞品池的第三层（直接竞品 / 间接替代 / 点名参考），在 §3—§10 的每一节里与其它竞品同列参与横向对比。 + +🔴 目标：从产品视角横向拆解竞品，讲用途、讲场景、讲功能、讲作用、讲优势（2026-10-07 用户口径）。 + +🔴 核心模型 = 五问（用途 → 场景 → 功能 → 作用 → 优势），本份每一节都在回答其中一问或几问。 + +执行： +1. 读 `references/competitor-analysis.md`（唯一方法论载体，含 §0 Scope 与文末《输出检查》） +2. 按项目目标圈定竞品范围（直接竞品 ＋ 至少 1 个替代/间接方案 ＋ 点名的参考实装） +3. 先出独立分析体：竞品池里每一个一份，按 §11 的七节写（哪些节能答、哪些答不了，由 §11 的「取证范围 ↔ 可答节次」定） +4. 再出汇总对比体：按 用途 → 场景 → 功能 → 作用 → 优势 横向比（按用户处境横向铺开，不按竞品逐个写） +5. 输出优势与不足、可借鉴点与产品机会 +6. 交付前走一遍该方法论文末《输出检查》：任一条为「否」⇒ 退回修改，不交付 + +🔴 最低输出结构（最低要求，按品类可增不可缺）： + +甲 · 汇总对比体（`research/1b-竞品分析.md`，恒一份）： + +| # | 节 | 回答什么 | +|---|---|---| +| 1 | 分析目标与范围 | 这次要回答什么；五问各落在哪节 | +| 2 | 竞品选择与范围 | 选了谁、属哪一层、为什么是它 | +| 3 | 竞品用途 | 是什么 / 给谁用 / 干什么用 | +| 4 | 使用场景横向对比 | 用户什么时候、为什么用；怎么把事办成 | +| 5 | 功能横向对比 | 有什么能力 / 解决什么问题 / 起什么作用 | +| 6 | 产品机制与交互方式 | 怎么解决 / 为什么这样设计 ⇒ 给用户什么结果 | +| 7 | 优势与不足 | 能力表现 × 场景 × 对比对象 × 用户价值 | +| 8 | 竞品能力矩阵 | 共识 / 差异 / 独有 / 普遍短板 / 未解决需求 | +| 9 | 可借鉴点与产品机会 | 该借鉴 / 该避开 / 可突破 | +| 10 | 结论（产品层） | 本产品应优先解决什么 | + +乙 · 独立分析体（`research/1b-独立分析/<竞品名>.md`，每个竞品一份；结构细则与判据见方法论 §11）： + +| # | 节 | 回答什么 | +|---|---|---| +| 1 | 它是谁、属哪一层、为什么纳入 | 竞品名 / 所属层级 / 纳入理由 | +| 2 | 用途 | 是什么 / 给谁用 / 干什么用 | +| 3 | 场景 | 用户在什么处境下用它；把事办成的实际过程（取不到就显式标缺口） | +| 4 | 能力 | 有哪些功能 / 各解决什么问题 / 起什么作用 | +| 5 | 机制 | 怎么做到的；为什么这样设计 ⇒ 给用户什么结果 | +| 6 | 强在哪、弱在哪 | 能力表现 × 场景 × 对比对象 × 用户价值 | +| 7 | 对我们 | 该借鉴 / 该避开 / 可突破 | + +其中第 2 / 3 / 6 节是必答项，写法固定（每组几行、每行叫什么、什么顺序都定死，取不到就照写「取不到」）；第 1 / 4 / 5 / 7 节写法自由。行名与行数见方法论 §11，本表不复述。 + +⭐ ①段就是上表这 5 个子步，每个子步一个方法论载体。产出份数上，1b 是唯一一个交两种体例的子步（独立体多份 ＋ 汇总体一份），其余四个子步各一份。这套结构直接服务单机自用的产品（用户本人就是唯一使用者）。 +（历史：本段曾有过另外几个子步、以及一次子步合并，为什么收成 5 个 → `_留痕/①段-已删除产出与方法论.md`） + +## 1c 用户画像（外部取证） + +| 子步 | 读 | 产出 | +|---|---|---| +| 用户画像 | `references/user-personas.md` | `docs/pm/<项目>/research/1c-用户画像.md` | + +## 1d 产品策略（判断） + +| 子步 | 读 | 产出 | +|---|---|---| +| 产品策略 | `references/product-strategy.md` | `docs/pm/<项目>/research/1d-产品策略.md` | + +## 1e 使用场景（判断） + +| 子步 | 读 | 产出 | +|---|---|---| +| 使用场景 | `references/usage-scenario.md` | `docs/pm/<项目>/research/1e-使用场景.md` | + +⭐⭐ 《使用场景》就是用户故事（2026-10-06 用户定案）：按「用户如何使用、解决什么问题」来梳理，唯一句式为 + +``` +作为【谁】，当【什么处境】，我要【办成什么】，这样【得到什么结果】 +``` + +四个槽位缺一不算完成；「我要办成什么」里不许出现功能名（出现即越界到②段）。 +它是②段功能清单的直接推导依据——②段每列一项功能，都要能追回本份的某一条场景；②段按使用场景梳理功能（一条场景可跨多个页面）。 +本份就是用户故事，`1e-使用场景.md` 一份承载全部，②段的功能清单直接追回本份。 +旧三段式（处境 / 现在怎么凑合 / 不用会用什么）改挂到四槽位：处境 → 「当…」；凑合与替代 → 「这样…」的反面与对照。映射表见 `references/usage-scenario.md` §5。 + +⭐ 1d《产品策略》与 1b《竞品分析》都落在产品层，回答"谁在什么处境下拿它办成什么事、做哪些功能、强在哪"，面向本产品自用的定位。 +（历史：本段原还挂过两份面向售卖场景的方法论，若某个项目真要做售卖可从 `_留痕/①段-已删除产出与方法论.md` 取回） + +## 「需求文档」在本段的落点（2026-10-02 定 · 2026-10-06 更新，避免误搬家） + +段名定为「产品需求」后，容易误以为②段那两份该搬进本段。不搬，理由如下： + +| 文档 | 归属 | 为什么 | +|---|---|---| +| `research/1a-需求文档.md` | ①段 | 做什么 / 为谁 / 不做什么 ＋ 决策表 | +| `research/1b-竞品分析.md` | ①段 | 别人做了什么、我们差在哪（含点名的参考实装） | +| `research/1c-用户画像.md` | ①段 | 用户是谁、要办成什么事（须追到原话） | +| `research/1d-产品策略.md` | ①段 | 为什么值得做、边界与风险 | +| `research/1e-使用场景.md` | ①段 | 用户怎么用它；使用场景 = 用户故事 | +| `docs/pm/<项目>/prd/2a-产品功能.md` | ②段 | 它是功能清单（做哪些 / 不做哪些 / 优先级 + 每条的状态流转） | +| `docs/pm/<项目>/prd/2b-界面布局.md` | ②段 | 它是页面骨架（页面关系 + 页面内板块布局——有哪几页、每页几个板块） | + +> 分界线一句话：①段回答「要解决什么问题、用户怎么用它」，②段回答「要做哪些功能、长成什么骨架」。 +> 判据：一份文档若主体是功能条目的有无与优先级、页面与板块骨架 → 归②；若主体是问题、用户、取证与取舍理由 → 归①。 +> ⚠️ 2026-10-06 边界更新：②段从"不给页面结构"改为"给骨架"，页面关系与页面内板块布局必须在②段确认。 +> 修订后分工与用户原话：只在②段 `references/stage-requirements/SKILL.md` 的 §②—③ 交接口 定义一次，本段不复述。 + +## 硬约束 +- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。 + +- 需求文档必做：`1a-需求文档.md` 存在（含"做什么 / 为谁 / 不做什么"＋决策表），且待复核清单已被用户过一遍。没有它不许开 1b——否则取证答的不是用户的问题。 +- ⭐⭐ 产出白名单（2026-10-06 用户定案）：本段产出仅五份（见开头「产出白名单」）。不许新增第 6 份，除非用户明确要求。 +- 自动补全要留痕：模型替用户补的答案必须标 `【假设】` + 理由 + 影响范围，并进待复核清单。用户始终不回应时，在该文件顶部写明"本表 X 项为模型假设，未经用户确认"。 +- ⭐ 状态行不许只写好消息（2026-10-02 新增）：`1a-需求文档.md` 顶部状态行必须同时给出「已确认 N 项 / 模型补全 M 项（M 项未经用户确认）」两个数。"frontier 为空""无遗留未决项"这类单边表述不得单独出现——它与正文"5 项是未经确认的假设"并存时，只读首屏的人会以为需求已澄清。 +- ⭐ 假设三归宿，不许长期悬空（2026-10-02 新增）：每条 `【假设】` 只能落在三种归宿之一——① 已确认（去掉标记，写明谁何时确认）② 待实现且已排定确认时机（写明"在第几步落地前必须问"）③ 已按假设落地（改标 `【已按假设落地】` ＋ 写清影响面 ＋ 给出回退口径）。第四种状态（既未确认、已进实现、又无落地说明）不许存在。实测：约 10 条假设从 09-24 挂到 10-02，而原型已做到 v16——假设错一条，返工面就是整页。 +- ⭐ 待确认 / 暂缓项必须带回收三字段（2026-10-02 新增）：任何写"待确认 / 暂缓 / 待定"的条目，必须同时写 复核人 ＋ 复核时机 ＋ 结论落点（哪个文件哪一节），三字段缺一不许落盘。只写"暂缓"等于无限期悬挂。 +- ⭐ 用户画像必须能追到原话（2026-10-02 新增）：`1c-用户画像.md` 里每条 JTBD / 痛点必须能追到一句用户原话或一条可核的观察；追不到的标 `【推演】`，且 `【推演】` 不得进 1d 当依据。提问只问已经发生的事：问最近一次是什么时候、问上一次怎么处理的、问当时最费劲的是哪一步，不问"将来会不会用""你想要什么"。⚠️ 实测踩坑：三个 JTBD（「此刻的我 / 确认时刻的我 / 三个月后的我」）全是同一个人的三种时刻、零外部取证——那是自证，不是用研。 +- 调研不求全：只做影响本次决策的那几项，其余跳过并说明为什么跳过。 +- 区分事实与假设：来自检索或访谈的标 `【事实】`，推断的标 `【假设】`。1d/1e 的每条结论必须能追到 1b/1c 的某份文件或 `1a-需求文档.md` 的某一行；追不到的按假设处理。 +- ⭐ 1a 与 2a 的分工不许混（2026-10-02 段名对齐，2026-10-06 更新）：1a 定「问题与边界 + 形态与状态」（要做的东西凭什么成立、做成什么样），2a 定「功能与取舍」（要做哪些功能、哪些明确不做、页面骨架怎么排）。1a 不许写功能清单（那是 2a），2a 不许重开需求（那是 1a，含 2026-10-06 从②段合并进来的 B 节压测）。 +- ⭐ B 节合并后 `grill-me` 只此一份（2026-10-06）：②段不再有独立的 `grill-me.md` 与 `grill-decisions.md`，其二者的内容（做成什么样 / 状态怎么流转 / 哪些情况不成立）全部落进 `1a-需求文档.md`。不许把 B 节再挪回②段。 +- 段内子步之间不反问，做完直接进下一个子步。停线规则（哪几种情况停、怎么判）见 `product-planning` 的「执行规则」—— ⛔ 本段不复述，免得两处漂。 +- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。 + +## 完成标准 + +- `1a-需求文档.md` 存在（含"做什么 / 为谁 / 不做什么"＋决策表），每项都标了来源（用户拍板 / `【假设】` / `【事实】`） +- 顶部状态行给出「已确认 N / 模型补全 M（未经确认）」两个数；每条 `【假设】` 都能在三种归宿里找到自己（已确认 / 待实现已排时机 / 已按假设落地） +- 1b 竞品分析 + 1c 用户画像 + 1d 产品策略 + 1e 使用场景 四份齐全 +- 🔴 **输入缺失时怎么办（①段唯一分支，2026-10-16 补）**：四份凑不齐（缺取证源／用户当轮只要 1a／本轮预算不够）⇒ 收口时交一份**显式豁免清单**，逐条写清三样：①哪几份不做、②为什么、③谁拍的板（用户原话或拍板时间）。清单落段末报告，并同步进 `索引-当前权威版.md` 的当下状态行。 + ⛔ 不交豁免清单就收口 ＝ 本完成标准没满足；⛔ 也不许拿「上游缺失」当许可，让②段自己去猜功能有无。 + ⭐ **豁免不等于放空**：`research/1a-需求文档.md`（含 A/B 两节决策表）**无论如何都要在** —— 它是②段在 `1e` 缺失时的**退化输入**（见 `references/stage-requirements/SKILL.md` 的「来自哪条场景」）。 +- 🔴 **已落进下游成品的场景内容，在①段落点处留指针**（2026-10-16 补）：实测本项目 7 条使用场景（`S001`–`S007`）只存在于④段成品「四、使用场景」一节，`research/1e-使用场景.md` 从未落盘。这类情况⛔ **不改成品**，而在①段的落点清单里写一行**指针**（格式照抄）：「本轮 `1e` 的内容见 `designs/<项目>/产品文档.html` 的〈四、使用场景〉节（`S001`–`S007`），⛔ 未回填成 `research/1e-使用场景.md`」—— 让下游知道内容**在哪**，而不是以为它不存在。 +- ⭐ 1b 两种体例都交了（2026-10-07 新增）：`research/1b-竞品分析.md`（汇总对比体）且 `research/1b-独立分析/` 下竞品池每一个一份（独立分析体）——只交一种 ⇒ 1b 没做完 +- ⭐ 目录里不出现白名单外的任何文件（第 6 份须有用户明确要求；`1b-独立分析/` 子目录是 1b 既定体例，不算第 6 份） +- 1d/1e 每条结论都标了来源（哪份取证文件或本表哪一行，或 `【假设】`） +- ⭐ 五份都过了「说人话」内容准则（源技能、判据与门槛见 `product-planning` 的「执行规则」内容准则条）；段末报告须写明"已过内容准则，评分 X/50" + +## 反面清单 + +- 跳过需求文档直接开取证，拿着自己的猜测去查资料 +- 把自动补全当默认动作：用户没说话就替他拍板，还没标 `【假设】`、没进待复核清单 +- 拿本段的需求文档代替第②段的功能压测（那是两件事——②段已无压测，压测在 1a 的 B 节） +- 在本段 1a 写功能清单（那是 2a 的活；1a 只定问题与边界、形态与状态） +- 只做 A 节、跳过 B 节（2026-10-06 新增）：B 节即原②段的功能压测，跳过它等于把压测整个删掉，接口会带着没压测过的需求直接进②段与原型 +- 在 B 节把页面结构写死（2026-10-06 新增）：B 节只给粗粒度形态（有哪几页、大概几个板块）；精确板块清单与布局图归②段的《界面布局》 +- 产出白名单外的第 6 份文档（2026-10-06 新增）：不许因为"用户点名了某个参考产品/某份素材"就另立文档，写进 `1b-竞品分析.md` 里 +- 1b 只交汇总对比体、把独立分析省掉（2026-10-07 新增）：两份体例都要交（见 `references/competitor-analysis.md` §0.4）。也不许把独立体写成仓库取证记录，它必须按方法论 §11 的七节答产品面（用途 / 场景 / 能力 / 机制 / 强弱 / 对我们） +- 改本技能包的规则文件、却不过「说人话」这一关（2026-10-07 新增）：规则和产出同一把尺子，不许只给产出上锁、自己用另一套腔调写规则——口径见 `product-planning` 的「执行规则」内容准则条 +- 没有取证就直接写策略 +- 把 11 个子步全跑一遍充数 +- 事实与假设混在一起不标注 +- 拿"frontier 为空 / 无遗留未决项"当闭合声明，而正文里还挂着未经确认的假设——只读首屏的人会误读成需求已澄清 +- 凭空给 Importance / Satisfaction 打分：没有任何数据源支撑的数字，不许出现在交付物里 +- 五份没过「说人话」内容准则就落盘 —— 口径与门槛见 `product-planning` 的「执行规则」内容准则条 +- 把推演出来的用户画像当用研结论进 1c——三个 JTBD 若都追不到一句用户原话，那是自证不是用研 +- 越界去写②段、出原型或写原型说明文档（那是第②③④段） + +📎 本段删过的产出与方法论（原产出长什么样、为什么删、原反面清单里被撤掉的那一条）见 `_留痕/①段-已删除产出与方法论.md`，正文不展开；防复活由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` 机器判。 diff --git a/product-planning/references/_留痕/N6-补对齐-20261016/references/stage-proto-doc/SKILL.md b/product-planning/references/_留痕/N6-补对齐-20261016/references/stage-proto-doc/SKILL.md new file mode 100644 index 0000000..4a7a6b0 --- /dev/null +++ b/product-planning/references/_留痕/N6-补对齐-20261016/references/stage-proto-doc/SKILL.md @@ -0,0 +1,186 @@ +--- +name: stage-proto-doc +description: 产品规划第④段，原型说明文档。在③段已跑通的原型 HTML 上补说明区，并产出一份能独立阅读的产品文档：按七节铺开 —— 原型页面地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值，编号用 P 页面／S 场景／F 功能／J 二级功能，起手复制段内模板 `assets/产品文档模板.html`。当用户要给原型加功能说明区、写产品文档、做操作指引演示，或说「只做原型说明文档」时调用。 +--- + +# ④ 原型说明文档 + +## 定位 + +- 本段解释和记录**现有**原型：不重新规划产品，不重新设计界面。 +- 交付两份产物：原型内嵌说明区、可独立发送的产品文档。两份共用同一套编号、场景、流程与功能定义。 +- 原型是界面行为的核对依据；①段的决策表与②段的功能清单是业务意图的补充依据。 +- 两份产物都按**七节**组织（原型页面地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值），骨架与 `assets/产品文档模板.html` 同构；⛔ 不按状态轴分段，也不把原型的界面状态当成文档的层级（界面状态只在第七节里写）。 +- 说明区是注解层，不是产品功能。交付时明说，免得让人以为产品里真有一个说明页。 + +## 输入 + +| 来自 | 读什么 | 用来定什么 | +|---|---|---| +| ③ | `designs/<项目>/*.html` | 界面事实的唯一依据：页面、模块、控件、状态、交互、跳转、反馈 | +| ② | `docs/pm/<项目>/prd/2a-产品功能.md` · `docs/pm/<项目>/prd/2b-界面布局.md` | 术语口径、优先级、功能条目编号 | +| ① | `docs/pm/<项目>/research/1a-需求文档.md` | 需求来源与「不做什么」的边界 | + +- 原型是界面事实，需求资料只定业务意图；两者冲突时显式记录，不静默选一个。 +- **上游缺失时**：先把缺的那一段补出来（②段缺失就先要一份最小术语表）；用户不要补，就在文档里逐处标 `【假设】`，并在段末的偏离单里写明「本段未判术语一致」。 +- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来停下问用户，不猜。 + +顺序 4a → 4b → 4c。说明区先齐，再放演示引导。 + +## 4a 场景盘点（必做，最先） + +读 `references/doc-area-spec.md`。产出：页面清单（`P`）＋ 使用场景清单（`S`）＋ 功能清单（`F`）＋ 二级功能（`J`），编号先占好、各自全篇唯一并按展示顺序通排。 + +## 4b 说明区（两份产物） + +读 `references/doc-area-spec.md` 铺框架，读 `references/doc-language-spec.md` 定语言：两份产物写完后，逐句过它第五节的自检清单。 + +**产物 A · 原型内嵌说明区** + +- 写进原型 HTML 自身，不依赖外链。 +- 放在原型对应位置的下方，随当前所在的那一段一起变。 +- 含原型页面地址、页面结构、功能清单、使用场景、操作流程、页面导航、原型状态取值七节。 +- 不覆盖业务区域，不改既有交互逻辑；原型结构不适合直接嵌入时，给可插入的 HTML 片段与插入位置。 + +**产物 B · 独立产品文档** + +- 单独一个 HTML 文件，落 `designs/<项目>/产品文档.html`，双击能开，能单独发给不看原型的人。 +- ⭐ **起手先复制通用模板**：`assets/产品文档模板.html`（本段自带）。它已经定好七节骨架、页面地址清单、页面结构图、功能清单（含目标产品特有列）、场景表、横向流程图、页面导航、状态取值表；把 `<尖括号>` 占位逐个换成真实内容即可，⛔ 不要从空白页重写结构。 +- 模板里定死的口径，照着填：编号 P／S／F／J 各自全篇唯一并按展示顺序通排；功能区命名用用户的叫法；流程画成**横向**流程图且每步写清「页面／功能／操作／完成判据」，「操作」行用强调色；重点功能在功能名、说明、目标产品特有列三处同时标红。 +- 七节顺序固定，与模板同构（见下面「产品文档框架」一节）。 + +## 4c 演示引导（可选） + +读 `references/guided-tour.md`，给每条流程放「演示」按钮。**用户不要演示时整体跳过**，跳过就在段末写明「本段未做演示引导」，完成标准里对应的那几条一并免检。 + +## 产品文档框架（七节 · 与 `assets/产品文档模板.html` 同构） + +⭐ **起手先复制通用模板** `assets/产品文档模板.html`（本段自带）：它已定好七节骨架、页面地址清单、页面结构图、功能清单（含目标产品特有列）、二级功能表、使用场景表、横向流程图、页面导航、状态取值表；把 `<尖括号>` 占位逐个换成真实内容即可，⛔ 不要从空白页重写结构。 +模板里定死的口径照着填：编号 `P`／`S`／`F`／`J` 各自全篇唯一并按展示顺序通排；功能区命名用原型界面上的叫法；流程画成**横向**流程图；重点功能在功能名、说明、目标产品特有列三处同时标红。 + +### 一、原型页面地址 + +- 每个原型页一行相对链接：文件名 ＋ 一句它是什么；放在文档最前。 +- ⛔ 不写本机绝对路径，⛔ 不写说明句 —— 读者直接点开就行。 + +### 二、页面结构 + +- 给一张页面结构图，图上标出各页面与其下的功能编号（页面 `P00x`／功能 `F00x`）。 +- 页面层级写一级／二级；功能区命名用原型界面上的叫法。 + +### 三、功能清单（表格） + +列：序号／页面名称／层级／功能区／功能（`F00x` ＋ 名称）／功能做什么／功能细节／目标产品特有列（本项目＝租户列）／待开发。 + +- 一行 = 一项功能；功能名与原型界面上的叫法一致。 +- 重点功能在功能名、说明、目标产品特有列三处同时标红，并在「重点项」表里补一行（重点项／说明／相关编号）。 +- 二级功能（一项功能展开的多个选项）另起一张表：编号 `J001`…／二级功能项／产出什么／对应页面功能。 +- 模板列之外，每项功能还要补齐这四项才算写完： + **做什么** —— 写处理行为与可观察结果，不写功能口号。 + **入口在哪** —— 给到可定位的页面与控件。 + **输入边界** —— 覆盖输入类型、必填、格式、长度、范围；无输入的功能写「无用户输入」。 + **异常与恢复** —— 写异常触发条件、界面反馈、恢复操作；原型没体现就写「原型未体现」，不写成已实现。 + +### 四、使用场景 + +- 一行 = 一个场景，写「用户要办成的一件事」，不写模块名；编号 `S001`…。 +- 每条带 前提／目标／原型位置（写到「页面 → 模块 → 控件或状态」，能在原型上点到）。 +- 场景后标该场景下的条目数。 + +### 五、操作流程（横向流程图） + +- 每个场景一条横向流程图，每步写清 页面／功能／操作／完成判据，「操作」行用强调色。 +- 步骤链 2–6 步；起点满足场景前提，终点对应场景目标。 +- 步骤里的按钮、菜单、字段、状态名称与原型逐字一致；流程里不出现原型没有、也没确认过的操作。 + +### 六、页面导航 + +- 一条导航一段，写成「来源页 → 目标页」＋走法；单向跳转与打开方式一并写明。 +- 原型没体现的跳转写「原型未体现」，不写成已实现。 + +### 七、原型状态取值 + +- 一行一个取值，写清取什么值落在哪个界面。 +- 取值与状态名一律以原型为准；⛔ 不把页面层级当状态写。（已验证过 `?state=` 这类取值清单的界面，走这条；无此机制的原型写「无」） + +## 编号与关联 + +- 页面 `P001`…、使用场景 `S001`…、功能 `F001`…、二级功能 `J001`… —— 各自全篇唯一、按展示顺序通排。 +- 同一场景、同一功能在不同章节重复出现时复用同一编号。 +- 每项功能至少挂在一个页面（`P00x`）上，挂不上就标「未映射」。 +- 二级功能 `J00x` 必须标出它对应的 `F00x`。 +- 功能可以服务多个场景；多对多时逐项列出关联编号。 +- 页面、模块、控件的数量不等于功能数量。 + +## 语体口径 + +- **完整规范读 `references/doc-language-spec.md`**：术语来源优先级、逐条禁用清单、五组对错对照、以及一份逐句自检清单。写每一句都照它过，自检任一项不通过就改。 +- 元信息（条数、口径、读法）写进表格的列、条目的字段或表头里；标题后面与标题下面都不另起说明行（踩过的坑：在标题下用小字解释「这一节是什么、为什么这么排」，2026-10-14 用户第三次点名，前两次分别是原型的状态小字与章节注解）。 +- 客观、书面的说明文，一句话只表达一个主要意思。 +- 用确切的页面名、模块名、控件名、状态名与业务术语；同一个概念全篇同名。 +- 描述行为用可验证的动词：显示、输入、选择、提交、生成、跳转。 +- 区分「已实现／未实现／待确认」三种状态，各写各的。 +- **禁用清单**：营销话术、主观评价、模糊程度词（大概、尽量、适当）、无依据的效果承诺、「相关页面／适当提示／处理异常」这类无法定位的说法、第一人称、比喻、空转评价（「值得注意的是」「具有重要意义」）。 +- 缺失信息明确标记，不用推测性描述填空白。规则文件本身也用这套语体写。 + +## 硬约束 + +- 只用原型上真实存在的事实；每条说明都能在原型上指到对应元素。 +- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。 +- 不擅自新增页面、功能、需求、业务规则或交互。 +- 把静态展示与真实数据处理能力分开写；把模拟数据、模拟提交、演示反馈与真实后端能力分开写。 +- 把计划实现与已实现分开写。 +- 不遗漏编号，不重复分配编号。 +- 两份产物的名称、编号、范围、入口、行为描述必须一致。 +- 说明区不依赖外链，不破坏原型原有功能。 +- 原型与需求资料的差异显式记录。 +- 自动结论不写成人工认可：机器判定只能说「进入队列／待人工逐条查看」，不写成「通过／已认可」。 +- 段内不反问，做完直接进下一个子步；停线规则见 `product-planning` 的「执行规则」。 +- 原型是生成物时，改动走它自己的生成链，不手改产物。 +- ⭐ 文档前面必须配图（2026-10-15 用户令）：本段落盘的每份文档，正文（第一张表 / 第一小节）之前必须先给一张图 —— 本段画《页面结构图 ＋ 用户路径图》；用 `diagram-design` 画，⛔ 手写 Mermaid。图是正文内容，⛔ 不写成标题旁边或标题下面的注解小字。 + +## 完成标准 + +- 独立产品文档含规定的七节，顺序固定，双击能开（起手用 `assets/产品文档模板.html`）。 +- 原型内嵌说明区能在原型里直接找到并读到。 +- 每条使用场景有唯一编号 `S00x`，并带前提、目标、原型位置。 +- 每条场景至少一条横向流程，每条 2–6 步且能在原型中逐项核对；在原型上点不出结果的场景标 `funcOnly`（只写进功能清单、不画流程），并在段末待确认清单里写明为什么点不出来。 +- 每项功能的 做什么／入口在哪／输入边界／异常与恢复 都填了（编号 `F00x`）；二级功能标出对应的 `F00x`。 +- 引用的编号都存在，页面／场景／功能／二级功能四类各自唯一且按展示顺序通排。 +- 两份产物没有互相矛盾的描述。 +- 未确认事项都有标记，并在段末列出待确认清单。 +- 原型原有页面与交互通过回归检查。 +- ⭐ 独立产品文档前面配了页面结构图（用 `diagram-design`，⛔ 无手写 Mermaid） + +## 自查清单 + +- [ ] 输入原型能运行、关键交互能走完 +- [ ] 实际实现／模拟行为／待确认三者的界线划清了 +- [ ] 独立产品文档按七节顺序排好，起手用了 `assets/产品文档模板.html` +- [ ] 页面结构图已配（用 `diagram-design`，⛔ 无手写 Mermaid） +- [ ] 页面 `P00x`／场景 `S00x`／功能 `F00x`／二级功能 `J00x` 各自唯一且按展示顺序通排 +- [ ] 每条场景有前提、目标、原型位置 +- [ ] 每个场景一条横向流程，每条 2–6 步，每步写清页面／功能／操作／完成判据 +- [ ] 每项功能的 做什么／入口／输入边界／异常与恢复 都填了 +- [ ] 重点功能在功能名、说明、目标产品特有列三处同时标红 +- [ ] 二级功能都标了对应的 `F00x` +- [ ] 界面名称与原型逐字一致 +- [ ] 失效编号、孤立功能、未映射功能已清理 +- [ ] 两份产物同一套定义、可相互核对 +- [ ] 说明区没破坏原型运行 +- [ ] 上游缺失处已标 `【假设】` 并写进偏离单 +- [ ] 未做演示引导时已写明并免检对应条目 + +## 反面清单 + +- 只写页面介绍，不写需求、场景、流程和功能 +- 用功能模块代替需求，需求条数没法统计 +- 用「用户使用系统」这类泛化描述代替具体场景 +- 用「点击按钮后完成操作」代替可核对的步骤与结果 +- 用「支持多种格式」代替明确的输入边界或待确认标记 +- 用「发生错误时提示用户」代替异常条件、反馈和恢复路径 +- 把原型里的静态假数据写成真实业务数据 +- 把未实现、未验证、未定义的行为写成既有能力 +- 两份产物里功能名称、编号或流程对不上 +- 改原型业务逻辑去迎合文档描述 +- 以篇幅、术语数量或排版代替可验证的完整性 diff --git a/product-planning/references/_留痕/N6-补对齐-20261016/references/stage-requirements/assets/产品规划模板.md b/product-planning/references/_留痕/N6-补对齐-20261016/references/stage-requirements/assets/产品规划模板.md new file mode 100644 index 0000000..b592dd6 --- /dev/null +++ b/product-planning/references/_留痕/N6-补对齐-20261016/references/stage-requirements/assets/产品规划模板.md @@ -0,0 +1,58 @@ +# ②段产品规划模板（起手先复制本件） + +> 🔴 **怎么用**：起手先复制本模板，把 `<尖括号>` 占位**换成真实内容**，⛔ 不要从空白页重写结构。 +> 本件是②段两份产物的**体例单一定义** —— 两张表的表头与顺序都在这里定死： +> 落 `2a-产品功能.md` 时只抄「一、功能清单」那张表；落 `2b-界面布局.md` 时只抄「二、页面骨架」那张表。 +> **表头一行照抄**，⛔ 不许增删列、不许改顺序；列名里的 `<项目>` 按 `product-planning` 的「项目与路径约定」换成真实 slug。 +> 两份文档开头那张图（`diagram-design` 画的《页面与功能结构图》）按各自硬约束插在**标题之后、第一张表之前** —— 本模板不代画。 +> ⚠️ 第③段已有的成品（`designs/<项目>/产品文档.html` 的「三、功能清单」一节）是**列取材来源**，但它少了本段自有的四项（`来自哪条场景`／`优先级`／`状态流转`／`验收要点`）⇒ **照成品抄一遍会把②段的判据抄丢**，必须用下面这张 12 列的表。 + +--- + +## 一、功能清单（→ `docs/pm/<项目>/prd/2a-产品功能.md`） + +| 编号 | 页面名称 | 层级 | 功能区 | 功能 | 功能做什么 | 功能细节 | 来自哪条场景 | 优先级 | 状态流转 | 验收要点 | 本期做不做 | +|---|---|---|---|---|---|---|---|---|---|---|---| +| F001 | `<页面名>` | `<一级／二级>` | `<功能区名>` | `<功能名：动词开头的用户语言>` | `<一句话说清做什么>` | `<具体有哪些操作与显示，逐条>` | `S001` | `P0` | `<有哪几个状态、怎么迁移；无状态写「无状态」>` | `<可观察的完成判据>` | `<本期做／移出（移出须写复核时机）>` | +| F002 | `<页面名>` | `<一级／二级>` | `<功能区名>` | `<功能名>` | `<一句话>` | `<逐条>` | `S002` | `P1` | `<…>` | `<…>` | `<…>` | + +**列口径**（12 列，⛔ 不许省）： + +| 列 | 写什么 | 判据 | +|---|---|---| +| 编号 | `F001`、`F002`… 唯一且连续 | «编号唯一且连续» 是机核项；⛔ 不跳号 | +| 页面名称 | 这个功能落在哪一页；跨多页写多页名，用「／」分隔 | 每一个页面名都要能在 `2b-界面布局.md` 的「页面名」列里追到 | +| 层级 | 一级页／二级页 | 与 `2b` 同页的值一致 | +| 功能区 | 页面里的哪个功能区（页内分组名） | 同上，须能在 `2b` 追到 | +| 功能 | 功能名，一句话说清做什么（动词开头的用户语言） | ⛔ 不写实现名 | +| 功能做什么 | 一句话讲清用户拿它干什么 | ⛔ 不写「体验好」这类 | +| 功能细节 | 具体有哪些操作与显示，逐条列 | ⛔ 不许空着 | +| 来自哪条场景 | ①段《使用场景》的编号（`S001`…）；**`1e-使用场景.md` 缺失时**退化为追 `1a-需求文档.md` 决策表条目（写法见 `SKILL.md` 的「输入缺失时怎么办」） | ⛔ 追不回的条目该砍 | +| 优先级 | `P0`／`P1`／`P2` | ⛔ 不许凭空打分 | +| 状态流转 | 这个功能自身有哪几个状态、怎么迁移（不适用写「无状态」） | ⛔ 不许省成空白 | +| 验收要点 | 怎么算做完（可观察） | ⛔ 不写「体验好」这类 | +| 本期做不做 | 本期做／移出；写「移出」的必须带复核时机 | ⛔ 只写「暂缓」不算 | + +--- + +## 二、页面骨架（→ `docs/pm/<项目>/prd/2b-界面布局.md`） + +| 页面编号 | 页面名 | 层级 | 对应原型文件 | 板块清单 | 板块排列 | 跨页关系 | 板块下挂哪些 F | +|---|---|---|---|---|---|---|---| +| P001 | `<页面名>` | `<一级／二级>` | `` | `<板块名①；板块名②；…（灰块粒度，只报有哪些块）>` | `<自上而下／左右；顺序逐块列出>` | `<← 来源页：…；→ 目标页：…>` | `F001、F002` | +| P002 | `<页面名>` | `<一级／二级>` | `` | `<…>` | `<…>` | `<…>` | `<…>` | + +**列口径**（8 列，⛔ 不许省）： + +| 列 | 写什么 | 判据 | +|---|---|---| +| 页面编号 | `P001`、`P002`… 唯一且连续 | 机核项；⛔ 不跳号 | +| 页面名 | 页面叫什么 | 机核项：**页面条数 = 原型 `.html` 文件数**（不含产品文档等非原型件） | +| 层级 | 一级页／二级页 | 与 `2a` 同页的值一致 | +| 对应原型文件 | 这一页落在哪个原型文件（相对 `designs/<项目>/` 的文件名） | 文件必须真实存在 | +| 板块清单 | 每页有哪些板块，灰块粒度 | 机核项：**每个板块名都要能在目标产品整页快照的板块集里追到** | +| 板块排列 | 这些板块自上而下／左右怎么排 | ⛔ 不许只给清单不给顺序 | +| 跨页关系 | 从哪一页怎么跳到这一页、这一页怎么跳出去 | ⛔ 不许只给页面清单不给流转 | +| 板块下挂哪些 F | 每个板块承载 `2a` 的哪几条 F 编号 | 机核项：**这里挂的 F 在 `2a` 全追得到，`2a` 的 F 在这里也全追得到** | + +> ⚠️ 视觉类六词（配色／字体／间距／组件样式／动效／响应式…完整清单见 `SKILL.md` 的 §②—③ 交接口「归③段」列）在本模板里**一个字都不许出现** —— 本模板只管灰块粒度的骨架。 diff --git a/product-planning/references/_留痕/N7-返工-20261016/SKILL.md b/product-planning/references/_留痕/N7-返工-20261016/SKILL.md new file mode 100644 index 0000000..b9814fe --- /dev/null +++ b/product-planning/references/_留痕/N7-返工-20261016/SKILL.md @@ -0,0 +1,313 @@ +--- +name: product-planning +description: 产品规划总入口（唯一入口），四段式调度：① 产品需求 ② 产品功能 ③ 界面交互 ④ 原型说明文档。四段以 references/stage-* 承载，本文件是总调度与约束。可整段跑也可只调一段。当用户要做产品规划、从零做新产品、只做某一阶段、或不知道从哪开始时调用。 +--- + +# 产品规划总入口 + +> 本 skill 由模型按需自动加载，没有斜杠命令。对话里还没定出对象时，先按「项目与路径约定」定出 `<项目>`；定不出来就停下问用户，不要自行假设。 + +## 用途 + +用户丢来一句模糊想法（例如「我要做一个 AI 短剧分镜画布」）时，本 skill 判断该走哪一段，只做那一段的最小必要工作，产出可交付物，再推进到下一段。 + +本文件管调度与约束。各段怎么做，写在 `references/stage-*` 各自的文件里。 + +## 四段结构（可整段跑，也可只调一段） + +| 段 | 回答的问题 | 子步 | 调用 | 产出物 | +|---|---|---|---|---| +| **① 产品需求** | 要做的东西凭什么成立：什么问题、为谁、为什么值得做 | 1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景 | `stage-discovery` | `docs/pm/<项目>/research/*`。其中 1b 交两种体例：`research/1b-竞品分析.md`（汇总对比）＋ `research/1b-独立分析/<竞品名>.md`（独立分析） | +| **② 产品功能** | 要做哪些功能、什么不做、长成什么骨架 | 2a 产品功能 / 2b 界面布局 | `stage-requirements` | `docs/pm/<项目>/prd/2a-产品功能.md` 与 `docs/pm/<项目>/prd/2b-界面布局.md`（两份） | +| **③ 界面交互** | 长什么样、怎么操作 | 3a 视觉规范 / 3b 原型 / 3c GPT参考版 / 3d 审查打磨 | `stage-delivery` | `designs/<项目>/DESIGN.md`、`designs/<项目>/*.html`、`designs/<项目>/3c-GPT参考版.md` | +| **④ 原型说明文档** | 现有原型怎么用、每条功能落在哪个页面、坏了怎样、怎么核对（文档按七节铺：原型页面地址 → 页面结构 → 功能清单 → 使用场景 → 操作流程 → 页面导航 → 原型状态取值） | 4a 场景盘点 / 4b 说明区 / 4c 演示引导（可选） | `stage-proto-doc` | 原型内嵌说明区 ＋ 独立产品文档 `designs/<项目>/<产品项目名>.html`（两份共用同一套 P 页面／S 场景／F 功能／J 二级功能编号） | + +四段只通过落盘文件耦合。段间交接口如下，这是唯一的契约，越界即失效： + +| 交接 | 由谁给 | 给什么 | 给到哪为止 | +|---|---|---|---| +| ① → ② | ① | 问题定义、需求澄清决策表（含 grill 压测的 B 节：做成什么样 / 哪些情况不成立 / 状态怎么流转）、取证结论（1b 汇总对比体 ＋ 1b 独立分析体、1c 用户画像）、产品定位、《使用场景》＝用户故事（②段功能的直接推导依据） | 功能清单归②段产出，1a 写到需求与形态为止 | +| ② → ③ | ② | 功能清单（每条带优先级 ＋ 状态流转）、界面布局（有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系）、每页主操作、信息承载分档（主屏常驻 / 可点入） | 视觉归③段。骨架必须给全，骨架不给全，③段就一版一个样 | +| ③ → ④ | ③ | 已跑通的单文件原型 HTML（页面、模块、控件、状态、交互、跳转、反馈＝界面事实的唯一依据） | 说明区与独立产品文档归④段；⛔ ④段不重新规划产品、不重新设计界面 | + +> 口径：②段钉骨架，③段做皮肉。两侧逐行对照与用户原话只在②段 `references/stage-requirements/SKILL.md` 的 §②—③ 交接口 定义一次 —— 本入口不复述。要点两条：②段要给全「归②段」列；③段不许增删移动板块，缺板块回②段改。 + +> ②→③ 最容易搞坏。旧病灶：②段说「必须能读到」，③段读成「必须常驻主屏」，五类信息就全铺一屏成了信息墙。分档表把「读到」明确成「一次点击内可达」，防的就是这句歧义。骨架是灰块（有哪些块、什么顺序），③段给的是视觉与交互实现（排版、点哪有什么反馈、空态、响应式）。两件事各管一维，③段不会退化成照抄。 + +> 四段各占一个词，互不共用（2026-10-02 定）：产品 / 功能 / 界面 / 说明。改段名前先对照这张表；两个段名里出现同一个词，边界一定在漂。旧名「调研与方案 / 需求与结构」都含「需求」，③段旧名里的「交付」是三段共有的属性，都属名实不符，已改。 +> 🔴 **④段的沿革（2026-10-14 → 10-15）**：10-14 按用户令删掉**旧版**④段 —— 旧做法是往原型 HTML 注入说明区注解层（状态 → 场景 → 从左到右流程图 → 功能作用/输入边界/异常情况 三段 → 逐步骤演示引导），实测没法用，整段连方法论一并撤掉。10-15 用备份里的**新版**④段装上：改成「解释与记录现有原型」，交**两份产物**（原型内嵌说明区 ＋ 独立产品文档 `designs/<项目>/<产品项目名>.html`），内容先按四块＋附录铺，随后整套同步成**七节**（原型页面地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值），编号改用 P 页面／S 场景／F 功能／J 二级功能，并带一份现成模板 `references/stage-proto-doc/assets/产品文档模板.html`。判据正文在 `references/stage-proto-doc/`，⛔ 旧版那套（状态轴、三段必填、逐步骤演示）不再使用。 +> ①叫「产品需求」不叫「需求调研」：该段产出 `research/1a-需求文档.md`、`1b-竞品分析.md`、`1c-用户画像.md`，也产出 `1d-产品策略.md`、`1e-使用场景.md`，「调研」二字盖不住后半截。 +> ⭐ 1b 是①段唯一交两种体例的子步：独立分析体 `research/1b-独立分析/<竞品名>.md`（竞品池每一个一份），汇总对比体 `research/1b-竞品分析.md`（恒一份）。职责边界与定案原话见 `references/stage-discovery/references/competitor-analysis.md` §0.4。 + +⭐ `grill-me` 全场只有①段一份（2026-10-06 用户定案）：①段那份按 A / B 两节提问，火力点划分、节次归属与定案原话见 `references/stage-discovery/references/grill-me.md` —— ⛔ 本入口不复述。B 节结论落进 `research/1a-需求文档.md`。 + +⭐ ②段产出两份（2026-10-06 收窄，2026-10-07 定为两份）：`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 ＋ 状态流转）与 `docs/pm/<项目>/prd/2b-界面布局.md`（页面关系 ＋ 页面内板块布局）。定案原话与理由见 `references/stage-requirements/SKILL.md` 开头。 + +（交接口反转前的口径、②段收窄前的产出清单与去向 → `references/_留痕/③段与总入口-旧口径.md`） + +⚠️ ①段功能按「使用场景」组织（一条场景可跨多个页面），不按页面组织。 + +段内的子步顺序、方法论文档、硬约束、完成标准，都在各段自己的 `SKILL.md` 与 `references/` 里。 + +①段 1a 需求文档：全程最先做，且只做一次。用 grill-me 与用户互动，产出 `docs/pm/<项目>/research/1a-需求文档.md`（开头写清做什么 / 为谁 / 不做什么，往下是决策表）。 + +## 项目与路径约定（单一真源） + +> 四段全部遵守本节。各段 `SKILL.md` 与 `references/` 里出现 `docs/pm/...` 时，`<项目>` 一律指本节定义的 slug。 + +### `<项目>` 是什么 + +项目 slug 用小写字母、数字、连字符（例 `my-tool`、`video-canvas`）。它就是项目目录这一层的目录名，一个字都不能差，**两个根下同名**。产物**分两个根**落： + +| 根 | 路径 | 装什么 | +|---|---|---| +| 🔴 **文档根** | `docs/pm/<项目>/` | ①段 `research/`（`1a`~`1e`）、②段 `prd/`（`2a-产品功能.md` ／ `2b-界面布局.md`）、跨段 `专题/` | +| 🔴 **设计根** | `designs/<项目>/` | ③段 `DESIGN.md` ＋ 原型 `*.html` ＋ `3c-GPT参考版.md` ＋ 3d 审查留痕件 ＋ 截图 `_gate_shots/`；④段 `<产品项目名>.html` | + +⚠️ **②段 prd 归文档根**，⛔ 不跟③段一起搬 —— 它与①段 `research/` 同根，③段的机检脚本也按 `docs/pm/*/prd/2b-*.md` 去定位它（`find_doc`）。⛔ 已废的那层 `ui/` 子目录不要再写进任何判据。 + +### slug 怎么定（按序取第一个成立的） + +| 序 | 条件 | 取值 | +|---|---|---| +| 1 | 用户在当前会话里明确说了项目名 | 该名字 slug 化 | +| 2 | `.registry/current-project` 存在且非空 | 其内容 | +| 3 | `docs/pm/` 下恰有一个非 `_` 开头的目录 | 该目录名 | +| 4 | 以上都不成立 | 停下问用户 | + +写任何文件之前先核对：目标路径里的 `<项目>` 段与按上表得出的 slug 是否一致。不一致就停下说明，不要「先写了再说」——猜错会把产物写进别的项目，事后极难拆干净。 + +### 产物落哪 + +| 段 | 路径 | +|---|---| +| ① 产品需求 | `docs/pm/<项目>/research/` | +| ② | `docs/pm/<项目>/prd/` | +| ③ | `designs/<项目>/DESIGN.md`、`designs/<项目>/*.html`、`designs/<项目>/3c-GPT参考版.md` | +| ④ | 原型内嵌说明区（写进 `designs/<项目>/*.html` 自身）＋ 独立产品文档 `designs/<项目>/<产品项目名>.html` | + +### 文档的两态：当前版与过期版 + +用户令（2026-10-11 逐字）：「**应该有文件夹 专门归档过期文档， 当前文档 统一放在方案文件夹中**」。 + +🔴 **方案文件夹** ＝ `docs/pm/<项目>/` 这一层 —— 它下面放的全是**当前权威版**：①段 `research/`、②段 `prd/`、跨段 `专题/`，另加一份 `索引-当前权威版.md` 当入口。 + ⚠️ ③段与④段的产物**不在**文档根 —— 它们在设计根 `designs/<项目>/`（见上「产物落哪」）。⛔ 别按老口径去文档根下的 `ui/` 子目录找原型（那层已废，原型在设计根顶层与 `DESIGN.md` 同处）。 +🔴 **归档文件夹** ＝ `docs/pm/<项目>/归档-过期版/` —— 被顶替下来的旧版全放这里，命名 `<原名>__<来源目标短哈希>.<扩展名>`（例 `2b-界面布局-新版__fc471a.md`）。 + +**每个目标收口时做四步**： +1、本目标的权威文档**覆盖**方案文件夹里对应的那一份。 +2、被顶替的旧版**移进** `归档-过期版/`，按上面的命名补上来源短哈希。 +3、更新 `索引-当前权威版.md` 里对应行的大小与日期。 +4、执行区（`执行会话/目标-*/` 这类过程目录）里的原件**保留** —— 它既是过程留痕，也是台账 `artifact` 指向的地方，搬空会让回查断链。 + +**为什么要有这条**（避坑依据 · 2026-10-11 实测）：同一个 `2a-产品功能` 在 6 个目标目录里各有版本、`2b` 有 7 个，光看文件名与字节数分不出谁新；而 `docs/pm/` 下早先那次归档又停在旧版（`2b` 只 52 256 B，最新已是 52 643 B）⇒ 用户问「很多新老方案都在文件夹中，后续根据方案细化产品界面，如何找得到对应的方案」。判断某份文档的当前版，**只看方案文件夹**；问「当时为什么这么定」才去归档文件夹翻。 + +### DESIGN.md 为什么在项目目录、不在仓库根 + +`DESIGN.md` 是③段的绑定视觉规范，一个项目一份，③段按当前项目的 slug 去读它。仓库根只能放一份，多项目会互相覆盖，所以一律放 `designs/<项目>/DESIGN.md`（与原型同目录）。 + +推论（硬规则）：读 `DESIGN.md` 时，路径必须由本节定义的 `<项目>` slug 拼出，不许用「当前工作目录碰巧有 DESIGN.md」这类推断。仓库根不放任何项目的 `DESIGN.md`。 + +## 工具选择规则（防止选错，最重要的一节） + +> 下表是选型总则。这些工具都已封装在对应段内，本文件只负责让你不选错；具体调用路径见各段 `SKILL.md`。 + +| 要什么 | 用谁 | 别用 | +|---|---|---| +| 页面设计全链（规范 → 原型 → 审查） | ③段 `stage-delivery` 自己的 D0→D5 流水线 | 另找风格库，或自己手搓一套 token 与门禁 | +| 评审用的可点原型 / 生产级前端页面 | ③段 3b（按 D2 构建，单文件 HTML 交付）。先判页型：营销页取③段 §供给·版式骨架 的可选档，工具型页面取其默认档 | 不判页型就套可选档种子——那是营销落地页骨架，会把后台做成营销页 | +| 设计规范文件 | ③段 3a 生成 `DESIGN.md`（令牌表取自③段选定套，见③段 §供给·定调与令牌；再加该项目②段的界面需求） | 凭空编一套 token | +| 架构图 / 流程图 / 时序图 | `diagram-design` | 手写 Mermaid | +| 状态迁移的守卫、副作用、并发 | `state-machine` | 指望 diagram-design 覆盖这些 | +| 审美方向 / 风格定调 | ③段 §供给·定调与令牌 的默认档里选一套（可选档亦见该处），读候选套按页面类型挑。⛔ 每次只选一套 | 「米白＋衬线＋陶土色」这类默认审美，或凭感觉编 | +| 多方向比选 / 独立评审打分 | ③段 §供给·多方向比选 与 §供给·独立评审协议 | 拿它的评分循环替代本段 Gate-1/2/3 | + +③段的页面设计供给 —— 默认主线、定调与令牌、版式骨架、工艺数值判据、独立评审协议、多方向比选，共六档；各档的默认来源 / 可选来源 / 路径只在③段 `references/stage-delivery/SKILL.md` 的 §供给 定义一次，本入口不复述，要改供给只改那一块（2026-10-08 起）。`oil-ui-pro` 是界面设计方法论：五步流程（探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付），加风格对比页与截图工具；它自带联网版本检查与自动更新，是用户明确要求全量搬入的例外项（既有纪律是「依赖外部服务一律不收」），已记录在案，不扩散。 + +默认走 `oil-ui-pro` 主线，不与可选档缝成一条流水线：可选档只在 §供给 里列，选了才作补强（多一路定调候选、多一套工艺数值判据），不选也不影响开工。 + +四样东西供给件里都没有对应，由 `stage-delivery` 自己扛：设计契约十二字段、结构骨架、交互清单、工具型版式库。 + +页型分流（2026-10-05 新增）：③段 §供给·版式骨架 的可选档是营销落地页向，工具型页面照它做会长出「标题上下各一行小字」的三段式（骨架名单与理由见③段 `references/stage-delivery/references/layouts-tooling.md` 开头）。本项目实测踩过这个坑，结构判据全绿也拦不住。所以③段 D0 必须先判页型，工具型页面版式一律走 §供给·版式骨架 的默认档。 + +只读一处来源：同一条判据若在默认档与可选档各有一份且口径不同，以本项目追加条为准 —— ⛔ 但追加条不得放宽基础层（`oil-ui-pro` 是基础层、其余是叠加层，分层规则见③段 §供给），并在 runbook §3.4 显式标注「本项目追加」。 + +DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec` 四个子命令，目前是 alpha（v0.4.0）。非 TTY 的管道里可能不回显输出，需在真实终端里确认。本机实测该命令完全不可用，不要拿它当校验关卡；改由 D3 收口与 D5 终检按真实像素人工复测对比度（判据见③段 §供给·工艺数值判据 里配色那一份）。原两把门禁脚本（静态文案检查 / 渲染机检）已随旧主干从磁盘移除，当前没有机器复现，结论只能记「人工判定」，不得写成「脚本已通过」。 + +## 可调用工具（自然语言触发） + +> 两个独立工具，按用户说法直接触发，产物落项目目录。`design-capture` 随③段携带（装在③段 `references/stage-delivery/assets/` 下）；`video-capture` 2026-10-11 已独立成全局技能（装在**技能根**下的 `video-capture/`），跨段复用。两者都不单独成段。 + +| 用户说 | 触发工具 | 做什么 | 产物 | +|---|---|---|---| +| 「分析 XXX 视频」「把这个视频抽帧」「拆一下这条视频的画面」 | 全局技能 `video-capture` | 取视频（本地文件 / 直链 URL / 平台页经浏览器下到本地）＋ 抽帧（双因素 ＋ 首尾 ＋ 补帧） | 关键帧 `c_<序号>_<真实秒数>s.jpg` ＋ `frame_times.json`（供①竞品分析、③视觉参考） | +| 「获取 XXX 网站的设计风格」「抓这个网站的风格/组件/配色」 | `stage-delivery/assets/design-capture/` | 抓网页设计系统（色彩 / 排版 / 组件），生成样式模板 | 一套 `design-system-<名>/`（与 `design-system-tiaoyue` 同构，可直接被③段 D1 选用） | + +两者都独立可单跑：`video-capture` 只依赖 `ffmpeg`（权威件＝全局技能 `video-capture`；原 `stage-delivery/assets/video-capture/` 只留交接说明，脚本迁至 `references/_留痕/video-capture-已独立-20261011/` 留档）；`design-capture` 只依赖本机 Chrome（CDP）＋ `vendor/` 里搬运的抽取脚本，不需要任何外部服务在场。用法与边界见各自 `SKILL.md`，来源与署名见各自 `ATTRIBUTION.md`。 + +触发时机：①②段拆竞品视频用全局技能 `video-capture`；③段要新建样式或拆参考站用 `design-capture`。 + +两个工具都只做合规最小集：不抓平台页内视频，不调付费接口；抽取结果须先目视比对再采用。 + +## 进入方式 + +| 你说什么 | 模式 | 从哪开始 | +|---|---|---| +| 「规划 XX」「从零做 XX」 | 全流程（自动处理） | `stage-discovery` → `stage-requirements` → `stage-delivery` → `stage-proto-doc`，一路跑完，段间不停下来问（含①段末） | +| 「先确认方案」「跑完方案停下等我」「规划 XX，先给方案」 | 方案确认 | 同一套四段，唯一差别是①段末停下等你确认方案，确认后才进②③④ | +| 「只做产品需求」「只做产品功能」「只做界面交互」「只做原型说明文档」 | 单段 | 只调对应那一个 stage skill，不展开其他段 | +| 已有②段，要出原型 | 单段 | 直接调 `stage-delivery`，从它的 3a 起 | +| 已有原型，要补说明 | 单段 | 直接调 `stage-proto-doc`，从它的 4a 起 | +| 只问某个单点 | 单段 | 不跑任何段，在对应 stage skill 内点名子步，或直接说要看哪份方法论 | + +「只调一段」成立的原因：四段之间只通过落盘文件耦合，没有隐式状态。 + +- ②只读 `docs/pm/<项目>/research/*`；缺失时标注 `【假设】`继续，不催促回补① +- ③只读 `docs/pm/<项目>/prd/*`；缺失时同样标 `【假设】`继续 +- ④只读 `designs/<项目>/*.html`（界面事实的唯一依据），另按需读 `docs/pm/<项目>/prd/*` 与 `research/1a-需求文档.md` 定业务意图；缺失时标 `【假设】`继续，并在段末偏离单里写明 + +## 执行规则 + +只有三种模式，没有第四种： + +| 模式 | 段之间 | 段之内 | +|---|---|---| +| 全流程（自动处理） | 一路跑完，段间不停下来问（含①段末）。每段结束按「标准收尾格式」输出一段报告，输出完即刻进下一段 | 子步之间不反问，做完直接进下一个子步 | +| 方案确认 | 与全流程完全相同，只有一处不同：①段末停下等你确认方案；确认后②③④一路跑完、段间不停 | 同上 | +| 单段 | 不涉及 | 不越界，不催促回补前段 | + +这两条是全流程模式下的两个独立分支，不要混：全流程（自动处理）没有①段末的强制停；「停下等确认方案」只在「方案确认」模式下发生。二选一由用户定（界面里点【生成原型和文档】时选「自动处理」或「先确认方案」，或在会话里直接说明）；用户没明说时按自动处理走，不要在自动处理模式下自作主张停下来问。 + +「停下」指什么，不要读成「每一步都要反问用户」。只有这四种情况才停： + +1. 信息不足且查不到，必须用户给（如「项目与路径约定」slug 第 4 条）——停下问 +2. 破坏性 / 不可逆动作——二次确认 +3. 用户显式要求某个子步做完停下 +4. ①段末的方案确认（仅「方案确认」模式）——把方案摆给用户：做什么 / 不做什么 / MVP 边界 / 未复核的 `【假设】`，明说「等你确认方案，确认前不进②段」 + +段末报告：全流程（自动处理）模式下，所有段（含①）都只输出报告，不提问、不等回答；方案确认模式下①段是唯一例外，其余段同样只输出报告。 + +①段末的确认是回环，不是一次问答（仅「方案确认」模式）：用户看到方案后可以提问题要求改，可能多轮，每轮的「问题＋怎么改的」都要留痕、不得覆盖上一轮；改完由用户显式说「确认方案」才算过闸门。该模式下，没拿到用户确认的方案不得当成既定事实带进②段——这是实测踩过的坑：②段拿着未经确认的方案往下跑，把用户已拍板的需求裁掉了。 + +其余规则： + +- 声明制（全段适用，不止③段）：开工前、每进一个子段或子步、每处偏离，都要声明三件事——当前在哪、依据哪个文件的哪一节、产出落哪；偏离当场写明原因与影响，段末附偏离单。不许静默偏离。实测踩过的坑：③段 3b 交付了原型却没走当时声明的主流程、没读依据文件，也没当场说，用户追问「基于哪个 skill」才知道。 +- 不做八股：不介绍方法论来源，不列人名，不复述框架历史，直接给结论。 +- ⭐ 内容准则：一切落盘文字都要先过「说人话」这一关（2026-10-07 用户定案，同日扩大到规则文件）。用户原话：「当作第一步 和 第二步 生成文档时 必须遵循的内容准则」「不管是写规则 还是 写文档 都要严格按照说人话的技能去执行」。 + - 适用面两类都算，只改产出不改规则等于半改。一是产出文档：`research/1a-需求文档.md` 到 `1e-使用场景.md`（5 份）、`research/1b-独立分析/`（独立分析体）、`docs/pm/<项目>/prd/2a-产品功能.md` 与 `docs/pm/<项目>/prd/2b-界面布局.md`（2 份）。二是规则本身：本技能包内的一切落盘文字，`SKILL.md`、`references/**`、模板与清单。 + - 判据来源（单一可信源，本文件不复述模式清单）：**只有 `humanizer` 一份，且只用它的英文正式目录** —— `<技能根>/humanizer/references/patterns.md` 的 **P1–P55**（内容 8／语言与风格 10／沟通 3／填充与模糊 9／新兴 13／工艺与取证 12）。另有 5 种口吻档（casual / professional / technical / warm / blunt）。 + - 🔴 **判据一律用英文目录（2026-10-15 用户令）**：中文附录 `patterns.zh.md`（ZH1–ZH15）**只作参考线索，⛔ 不作判据** —— 作者自标「实验性、未经中文母语写手校验、不应被当作已验证的规则」。原中文版 `humanizer-zh` 的 24 条与五维 50 分表随该技能删除一并停用作废。 + - 门槛（2026-10-15 改）： + · **英文产出**：可读 `--score` 的 0–100 AI 痕迹密度分（越低越像人；上游 pre-commit 的拦截线是 40），本包不设硬阈值，分数写进段末报告。 + · **中文产出**：⛔ 不采信自动分数 —— 该打分器按 `[.!?]` 切句、按 `[a-z0-9]` 切词，中文 `。！？` 不切句、汉字零词，分数实际在测「文件里有多少拉丁字符」（实测：同一段中文把 `。` 换成 `. ` 分数不变；零拉丁字符的中文直接判 `No text`）。改按 **P1–P55 逐条人工对照**，再跑 `--check-facts` 保真（它只抽数字／日期／版本／URL／路径／标识符，中文同形可用）。对照结果与事实存活数写进段末报告，命中项不对完不许落盘。 + - ⛔ 取不到判据来源时（2026-10-08 补）：两份技能都不在位或读不到 ⇒ **不许凭感觉判「这条够人话」**。在段末报告与 3d 审查留痕件（`3d-审查报告.md` 或 `DESIGN.md` 审查节）里明写「无判据来源，本项未判」，按与 §供给·工艺数值判据 的「证据缺口」同一口径处理。 + - 五条核心原则（2026-10-15 起**就地固化在本包**；原引自已删除的 `humanizer-zh`《核心规则速查》，英文版 `humanizer` 的 Quick reference 没有等价条目，故不再指向外部）：删填充短语（开场白、强调性拐杖词）；打破公式结构（二元对比、戏剧性分段、修辞性设置）；变化节奏（长短交错，两项优于三项，段尾多样）；信任读者（直接陈述事实，跳过软化、辩解、手把手引导）；删金句（读起来像可引用的话，就重写它）。 + - 🔴 **适用面要划清（2026-10-15 排查后立）**：本包只取这份技能里**「去 AI 味」那一半**，⛔ 不取**「注入个性」那一半**。 + 取这些：英文模式目录 `references/patterns.md` 的 P1–P55、就地固化的五条核心原则、禁用清单。 + 不取这些：`Soul Injection Techniques` 整节（11 条）—— 它明写「有观点、别只报告事实」「用具体感官／体验细节代替抽象说法」「允许跑题与题外话」「结尾不必收束」「用 imperfect start 开场」，与本包产出要的**客观书面说明文**正好相反（照它写会出乱比喻、口水话、不能简明扼要）。该节第 3 条自带的示例就是「凌晨两点冷咖啡和看不懂的堆栈」这种感官化写法。 + 口吻档：本包产出**固定取 `technical`**（精确用词、一句一个意思、⛔ 无比喻除非确能澄清），⛔ 不用 casual／warm／blunt。 + ⛔ **已停用**：原中文版 `humanizer-zh` 及其五维 50 分表（该技能 2026-10-15 已整包删除，判据不再走它）。 + - 🔴 **同一件事更严的那份说了算**：④段的 `references/doc-language-spec.md`（客观书面说明文 ＋ 逐条禁用清单）是本包最严的一份语体规范；任一段落盘文字与它冲突，**以它为准**。 + - 交付留证：产出文档在段末报告里写明「已过内容准则，评分 X/50」；改规则文件时，在当日 memory 里记下这一关过了。 +- 只调一段时不越界：用户说「只做第 N 段」，就跑该段，不展开其他段，也不用「你还没做调研」去催促。 +- 提问上限 3 个：其余用合理假设，并在文档里标注 `【假设】`。例外是 `grill-me` 提问模式，不受此限（①段的「需求澄清」与②段的「需求压测」各一次），该模式的价值就是穷尽提问；此时须先声明「将连续多轮提问」，退出后恢复本约束。 +- 反问优先，允许自动补全：`grill-me` 的默认动作是把问题抛给用户并附推荐答案。用户说「你定」、连续两轮不回应、或属事实类问题时，模型自行给答案并标 `【假设】`，换来「不卡住」；但每轮结束要汇出待复核清单，未经复核的 `【假设】` 不得在下游当事实用。 +- 停线规则（**单一真源，全包只在本节写一次**，各段一律引用、⛔ 不复述）：只有三种情况停 —— ① 信息不足且查不到；② 破坏性／不可逆动作；③ 用户显式要求。 +- MVP 边界优先：任何阶段都先回答「第一版做什么、不做什么」。 +- 必须落盘：产出写入文件，不要只在对话里输出。 +- 无来源就标注：任何查不到来源的数据都标为「估算」并写明口径，不编造数字当事实。 +- 禁止长文：单份产出物默认一页纸（≤120 行），超长必须拆分。 +- ⭐ 落盘产出的排版（2026-10-14 用户令，原话「标题周围写小字的怪毛病 彻底改掉」）：元信息（条数、口径、读法、状态）写进表格的列、条目的字段或表头；标题旁边、标题下面、标题后面都只放标题本身。④段的 `references/doc-language-spec.md` 另有一份更细的，冲突以那份为准。 +- 🔴 路径写相对或占位（2026-10-14 用户令）：本包内一切文字（`SKILL.md`、`references/**`、脚本与注释、模板）引用**本技能自己或同根技能**的位置时，写相对形态 —— 同根技能写 `<技能根>/<技能名>/`，本包自己的文件写包内相对路径（如 `references/stage-delivery/`）。只有**跨根引用**（工作区根、文档库根、本机软件安装位这类从本包推不出来的别的根）才落到具体位置，且优先读环境变量（`DSH_WS_ROOT` / `DSH_DOCS_ROOT` / `WORKBUDDY_BIN_ROOT`）。原因：技能根的位置随环境变（全局技能根还是工作区技能根、用户名与盘符各不相同），写死了换台机器就是死路径，跨环境会整片报错。 + +## 征询外部模型（GPT）的提问口径（单一真源） + +> 🔴 2026-10-15 用户令，逐字：「问 GPT 的时候 只需要说明 关键背景情况和需求询问，禁止带入过多细节上下问造成干扰」。本包内一切向外提问的动作都按本节写；③段 3c 的提问模板是本节的一个实例，⛔ 不在别处另立一套口径。 + +- **要写三样**：① 场景一句（这是什么、要解决什么）；② 手上已有什么（只列与本次提问有关的）；③ 想问哪几个问题（逐条列，一条一个问点，末尾一句收口）。 +- **判据**：背景写到「对方能接住这个问题」为止 —— 少了这句，对方就问不出对的问题吗？问不出才留，问得出就删。 +- **⛔ 不带**：过程留痕、已废弃做法的设计细节、「我们为什么这么做」的来龙去脉、内部硬约束清单、字段与文件清单。这些会把回答拖进细节纠缠，占掉本该用在核心问题上的注意力。 +- **为什么**（避坑依据 · 2026-10-14 实测）：为问「原型说明文档该怎么写」，先铺了 1 500 余字的背景（含已废弃做法的 5 个设计点、4 条硬约束、7 个问题）⇒ 细节量压过问题本身。 +- **留痕**：提问原文与回答原文都要落盘；提问按本节写，⛔ 不把本机路径当内容（外部模型看不到本机路径，要么逐字内联、要么上传文件）。 + +## 产出文档开头必须有图（单一真源） + +> 2026-10-15 用户令，逐字：「产品规划页面 所有文档前面都要画图」。各段一律引用本节，⛔ 不在段内另写一套口径。 + +- 每份落盘文档**第一屏就给一张图**：图放在标题之后、正文之前 —— 不读正文也能先拿到全貌。 +- 图是**正文内容**，⛔ 不写成标题旁边或标题下面的注解小字（与上面那条排版红线同一件事）。 +- 图要**表达结构或流程**（二选一或兼具）—— 一张图看完就知道「由哪几块组成、怎么连起来」或「一件事分几步走」；⛔ 不做纯装饰性配图。 +- 图表达这份文档**覆盖的东西之间的关系**，按段定画什么： + · ①段（`research/` 五份）—— 画对象与流向：为谁解决什么、信息从哪来到哪去。 + · ②段（文档根 `docs/pm/<项目>/prd/` 两份）—— 画页面骨架：有哪几页、每页几个板块、跨页关系怎么走。 + · ③段（`ui/` 下的产物与 `DESIGN.md`）—— 画页面结构与操作动线：用户办成一件事实际经过哪几页、每页做什么、哪里要来回跳。 + · ④段（产品文档）—— 画页面结构图（各页面与其下的功能编号）＋ 用户路径：各场景怎么串起来。 +- 画图用 `diagram-design`，⛔ 不手写 Mermaid（判据见「工具选择规则」那张表）。 +- 图里每格写清名字、线标方向；图与正文互相对得上 —— 正文新增或改了结构，图要跟着改，两处不许各说各的。 + +## 每段的标准收尾格式 + +``` +## 本段结论 +- （3-5 条，可直接决策的话） + +## 已落盘 +- ... + +## 待确认（最多 3 条） + +## 建议下一步 +→ 用 完成 <具体事> +``` + +## 反面清单 + +- 为一个小功能跑完整调研 +- 输出长文却给不出一个结论 +- 跳过「不做什么」 +- 用户只问单点，却强行拉进全链路 +- 把估算数据写成确凿事实 +- 跳过③段 D0 的 Gate-1（未定死令牌表与设计契约）就开写页面代码 +- 在 `grill-me` 提问模式下仍套用「提问上限 3 个」，把提问做成走过场 +- 只跑一次 `grill-me`：①没定义需求就去取证，或②拿①段的需求定义代替功能压测直接写②段 +- 把自动补全当默认动作：用户没说话就替用户拍板，还没标 `【假设】`、没进待复核清单 +- 手写 Mermaid 代替 diagram-design，手写 token 表代替 DESIGN.md +- 绕过四段自己手搓，或重写它们的内容（该调 `stage-*` 就调） +- 把供给件的内部路径按本 skill 目录去拼，或改它们的正文 —— 供给件指③段自带的 `oil-ui-pro`，以及 §供给 各档落在 `assets/` 下的件（它们是随③段携带的供给件，改动只写 `stage-delivery` 自己的 `SKILL.md` / `references/`；默认档与可选档平行，不缝成一条流水线，也不把 `oil-ui-pro` 的评分循环当成本段 Gate 的替代） +- 猜 `<项目>`：定不出来还硬写，把产物落到别的项目目录下 +- 把 `DESIGN.md` 写到仓库根：多项目会互相覆盖 +- 段间停下来问「要不要继续」：全流程（自动处理）模式下直接进下一段，只在段末输出报告 +- 把两种模式混用：在自动处理模式下自作主张停下问方案，或在「方案确认」模式下确认前就开跑②③④ +- 在「方案确认」模式下把①段的方案当成已确认就往下跑：该模式下①段末必须停下等用户确认（含「不做什么」） +- 下游擅自裁剪上游已拍板项：②③④发现要砍①段或决策表里已拍板的东西时，不许自行裁掉或改口径，必须列成「与已定决策的差异」交用户显式确认 +- 把模式当成段：模式是「要不要在①段末停」的开关，不是第五个段，别为它单独造段或造产物 +- 跑了却不说：没声明当前段 / 子步与依据文件，或偏离了被调 skill 的主流程却不声明、不记偏离单（应为：开工先声明、每个子步再声明、偏离当场声明） +- 让③段顺手把说明区或产品文档写了（那是第④段 `stage-proto-doc` 的活） +- ④段里重新规划产品、重新设计界面，或写原型上没有的页面 / 功能 / 业务规则（④段只解释与记录**现有**原型） +- 问外部模型时堆砌背景：把过程留痕、废弃做法、内部约束清单整段贴进去（应按「征询外部模型（GPT）的提问口径」只给关键背景 ＋ 明确问题） +- 落盘文档开头不给图，或图与正文各说各的（应按「产出文档开头必须有图」先上图、再写正文，两处对得上） +- 过「说人话」时把「注入个性」那半也照做：加观点、加第一人称、写感官细节与比喻、允许跑题（应按内容准则只取「去 AI 味」那半，产出仍是客观书面说明文） + +## 改名 / 改供给后的自检 + +```bash +python scripts/check_naming.py --ws <工作区> +``` + +它查四段段名与子步名在「总入口 ↔ 各段 `SKILL.md` ↔ 各段 `references/`」之间有没有漂，包括 H1 与子步表是否一致、总入口子步列有没有漏项、runbook 必读表有没有引用已移除的资产、两份副本是否一致。纯静态比对，不需要渲染，不需要外部依赖。 + +为什么必须有它：实测当天漏过两次，当时没有任何门禁会报错。 + +第一次（2026-10-02）：改段名时 `SKILL.md` 改了，但 `references/stage-discovery/references/grill-me.md` 的 H1 仍写「需求澄清（grill-me · 调研段）」；`references/stage-requirements/SKILL.md` 子步表写「2b 功能流转」而正文 H2 写「## 2b 状态机」；总入口④段子步列只写「4a 说明区 / 演示引导」漏了 4b / 4c。三处都只能靠回读发现。 + +第二次（2026-10-06）：②段收窄为「只细化功能」（7 份产出变 1 份）后，各段 `SKILL.md` 都改了，但总入口的三处仍写着旧结构——四段表的②段子步列仍是「2a 功能定义与压测 / 2b 功能流转 / 2c 功能图示」，四段表的①段子步列「1c 产品定位与商业设计」未随段内改名（段内已改称「产品定位与场景」），正文仍写「①与②各跑一次 `grill-me`」并指向两份同名文档，实际全场只有①段一份。闸门当场报 6 个 FAIL，根因是「改了承载段、忘了总入口」。 + +由此立一条硬纪律，与「换供给不能只改承载段」同型：凡改子步结构 / 段内产出清单 / 段间交接口，必须连带改总入口 `product-planning/SKILL.md` 的「四段结构」表与「交接口」表，不改就是半改状态。 + +改了段名 / 子步名 / 判据供给源之后必须跑一次，并把结果记进当日 memory。改完不校验，下次读契约的人拿到的是错的配方。 + +本脚本只查文本一致性（H1 ↔ 子步表 ↔ 总入口 ↔ 副本），查不出「判据口径是否自相矛盾」。例如「②段到底该不该给页面结构」这种反转，闸门一个字都报不出来。口径类改动要靠人工回读，且必须把反转理由与用户原话写进文档留痕。 + +脚本输出里的 `[提示]` 项（旧名出现）不计入失败，但要人工看一眼是不是落在「废止理由块」里——落在里面是正当留痕，散落在正文里就是真残留。 + +2026-10-07 起本技能只在全局一份：技能根下的 `product-planning/`。它就是本体，不再有「主 / 副 / 装入」三副本，也不再需要「三处 md5 复核」（那只在有副本时才有意义）。改完只跑一次 `check_naming.py --ws <工作区>`。用户原话：「把产品规划复制到 workbuddy 全局skills中 后续维护和使用全局技能」。工作区原先那三份已归档到 `归档/技能迁全局-20261007/`（未直删，可随时取回）。 diff --git a/product-planning/references/_留痕/N7-返工-20261016/references/stage-delivery/scripts/_common.py b/product-planning/references/_留痕/N7-返工-20261016/references/stage-delivery/scripts/_common.py new file mode 100644 index 0000000..b83af9a --- /dev/null +++ b/product-planning/references/_留痕/N7-返工-20261016/references/stage-delivery/scripts/_common.py @@ -0,0 +1,166 @@ +#!/usr/bin/env python +# -*- coding: utf-8 -*- +"""③段闸门脚本的共用件：定位、运行环境发现、自检文本的解析规则。 + +🔴 **解析规则只在这里写一份** —— `run_viewports.py` 与 `mutate_test.py` 都从这里取， + ⛔ 不许各自再写一遍正则（同一条判据两份实现 ⇒ 迟早一处改一处漏）。 + +## 原型自检输出要按这个骨架打印（③段的契约，⛔ 不是"某个项目的习惯"） + +原型自检区（`#selftest-out`）对每个列表页要打印**两行中的一行**： + + P <页名>：首屏从 px 起，行距 px，一屏装得下 行 ← 达标时 + P <页名>一屏只能装下 行（首行顶 px、行距 px） ← 不达标时 + +还要打印这四类全局项： + + 七页逐页查横向溢出：全为 0（最差 <页>） ／ 有页面横向溢出：<页> 超出 px + 顶栏高 px · 侧栏 ×px + 纵向滚动只由主区承担：.app 高 px + 自检结果：PASS ／ FAIL + +理由：闸门靠**读数**判达标（一屏行数、行距、横向溢出、外壳高度链）， +读数只能从自检文本里取；把骨架固定下来，解析规则就不必跟着项目改。 +""" +import glob +import os +import re +import shutil +import sys + +# Windows 控制台默认不是 utf-8 ⇒ 中文输出会炸在最后一步（退出码看着正常、日志是乱码） +try: + sys.stdout.reconfigure(encoding="utf-8", errors="replace") + sys.stderr.reconfigure(encoding="utf-8", errors="replace") +except Exception: + pass + +# ── 自检文本的解析规则（唯一一份）──────────────────────────────────────────── +PAT = { + "summary": r"自检结果：PASS\s*(\d+)\s*／\s*FAIL\s*(\d+)", + "row_ok": r"P(\d+)\s*[^\n：:]*[：:]\s*首屏从\s*(\d+)\s*px\s*起[，,]\s*行距\s*(\d+)\s*px" + r"[，,]\s*一屏装得下\s*(\d+)\s*行", + "row_bad": r"P(\d+)\s*[^\n]*?一屏只能装下\s*(\d+)\s*行", + "overflow_ok": r"[^\n]*逐页查横向溢出：全为\s*0（最差\s*(\w+)）", + "overflow_bad": r"有页面横向溢出：(\w+)\s*超出\s*(\d+)\s*px", + "topbar_nav": r"顶栏高\s*(\d+)\s*px\s*·\s*侧栏\s*(\d+)×(\d+)\s*px", + "shell_ok": r"纵向滚动只由主区承担：\.app\s*高\s*(\d+)\s*px", + "console": r"控制台报错：(.+)", +} + + +def parse_selftest(text, min_rows=6): + """把自检文本解析成一行一页的读数表。 + + @return dict： + · `pass`/`fail`：自检自报的 PASS／FAIL 计数 + · `rows`：{页号 int: {"cap": 一屏行数, "top": 首行顶 px, "pitch": 行距 px, "ok": cap>=min_rows}} + · `overflow_ok`/`shell_ok`：两条全局判据 + · `topbar`/`nav_w`/`nav_h`：几何读数 + · `console`：控制台报错摘要（"?" 表示自检没打印这一项） + """ + text = text or "" + d = {"rows": {}, "overflow_ok": None, "shell_ok": None, "console": "?"} + m = re.search(PAT["summary"], text) + if m: + d["pass"], d["fail"] = int(m.group(1)), int(m.group(2)) + for m in re.finditer(PAT["row_ok"], text): + p, top, pitch, cap = (int(x) for x in m.groups()) + d["rows"][p] = {"cap": cap, "top": top, "pitch": pitch, "ok": cap >= min_rows} + for m in re.finditer(PAT["row_bad"], text): + p, cap = int(m.group(1)), int(m.group(2)) + d["rows"].setdefault(p, {"cap": cap, "ok": cap >= min_rows}) + m = re.search(PAT["overflow_ok"], text) + if m: + d["overflow_ok"], d["overflow_worst"] = True, m.group(1) + else: + m = re.search(PAT["overflow_bad"], text) + if m: + d["overflow_ok"], d["overflow_worst"], d["overflow_px"] = False, m.group(1), int(m.group(2)) + m = re.search(PAT["topbar_nav"], text) + if m: + d["topbar"], d["nav_w"], d["nav_h"] = (int(x) for x in m.groups()) + m = re.search(PAT["shell_ok"], text) + if m: + d["shell_ok"], d["app_h"] = True, int(m.group(1)) + m = re.search(PAT["console"], text) + if m: + d["console"] = m.group(1).strip() + return d + + +# ── 运行环境发现（本机是托管运行时；换机器靠 env 覆盖）──────────────────────── +def find_node(explicit=""): + """定位 node：`--node` → `NODE_BIN` → PATH → 本机托管的最新一版。⛔ 不写死版本号。""" + for c in (explicit, os.environ.get("NODE_BIN", "")): + if c and os.path.exists(c): + return c + w = shutil.which("node") + if w: + return w + cand = sorted(glob.glob(os.path.join( + os.environ.get("WORKBUDDY_BIN_ROOT", r"E:\ProgramData\.workbuddy\binaries"), + "node", "versions", "*", "node.exe"))) + return cand[-1] if cand else "" + + +def find_harness(explicit=""): + """定位 browser-harness：`--harness` → `BH_BIN` → PATH → 用户 bin。⛔ 不写死路径。""" + for c in (explicit, os.environ.get("BH_BIN", "")): + if c and os.path.exists(c): + return c + w = shutil.which("browser-harness") or shutil.which("browser-harness.exe") + if w: + return w + cand = os.path.expanduser("~/.local/bin/browser-harness.exe") + return cand if os.path.exists(cand) else "" + + +# ── 文档／原型定位（按**目录形态**找，⛔ 不写死文件名）────────────────────── +def find_doc(ws): + """②段《界面布局》：`/docs/pm/<项目>/prd/2b-*.md` 里取**最新改过**的那份。""" + hits = glob.glob(os.path.join(ws, "docs", "pm", "*", "prd", "2b-*.md")) + return max(hits, key=os.path.getmtime) if hits else "" + + +# ④段产品文档的**首节标题**（七节定序的第一节）—— 它与原型同在 `designs/<项目>/` 一层， +# 靠**内容签名**区分。⚠️ 单靠关键名不够：实测本项目产品文档叫「灵感对话-短视频脚本.html」， +# 名字里没有「产品文档」三个字 ⇒ 只按名字排除会把它当成原型，闸门于是去查一份没有自检区的 +# 文件（定位错、报出来的错还像「原型坏了」）。 +DOC_SIG = "一、原型页面地址" + + +def _is_proto(path): + """判 `designs/<项目>/` 下的一个 html 是不是原型页。 + + 排除三类非原型件：`_` 开头的暂存件、④段的独立产品文档（名字以 `产品文档` 开头， + 或正文含首节签名 `DOC_SIG`）、③段落在那里的外部参考件（`3c-*` / `3d-*`）。 + ⛔ 不写死具体项目名；内容读不出时**放行**（宁可让它去报错，⛔ 不静默丢掉文件）。 + """ + if os.path.basename(path).startswith(("_", "产品文档", "3c-", "3d-")): + return False + try: + with open(path, encoding="utf-8", errors="ignore") as f: + return DOC_SIG not in f.read() + except OSError: + return True + + +def find_proto(ws): + """原型：`/designs/<项目>/*.html` 里取最新改过的那份（排除见 `_is_proto`）。""" + hits = [p for p in glob.glob(os.path.join(ws, "designs", "*", "*.html")) + if _is_proto(p)] + return max(hits, key=os.path.getmtime) if hits else "" + + +def resolve(ws="", doc="", proto=""): + """把（可选的）三条入参统一成绝对路径；缺的按目录形态自动找，找不到返回空串。""" + ws = os.path.abspath(ws or os.getcwd()) + return (ws, + os.path.abspath(doc) if doc else find_doc(ws), + os.path.abspath(proto) if proto else find_proto(ws)) + + +def die(msg, code=2): + sys.stderr.write("⛔ %s\n" % msg) + return code diff --git a/product-planning/references/_留痕/N7-返工-20261016/references/stage-discovery/references/grill-me.md b/product-planning/references/_留痕/N7-返工-20261016/references/stage-discovery/references/grill-me.md new file mode 100644 index 0000000..12c9b85 --- /dev/null +++ b/product-planning/references/_留痕/N7-返工-20261016/references/stage-discovery/references/grill-me.md @@ -0,0 +1,171 @@ +# 1a 需求文档（grill-me · grill 提问法 · 全场唯一一份） + +> 本文件是 `stage-discovery` 的方法论文档，由模型按需加载，没有斜杠命令。 +> +> 来源：`mattpocock/skills`（MIT）的 `grilling`。上游把 `grill-me` 做成只含一句 `Call the Skill tool with "grilling"` 的 stub，在这里属于多余跳转，故合并为一个自包含 skill 并做 PM 适配。 +> +> ⭐⭐ 2026-10-06 用户定案：「grill-me 也应该拿到第一步了，第二步就是细化功能」。 +> ⇒ 本份是全场唯一一份 grill-me，A / B 两节覆盖需求与功能两轮提问。 + +## 适用位置 + +PM 链路的①段 1a 需求文档，在任何一项调研之前先做（产出 `1a-需求文档.md`）。 + +起点对齐只写一句话（做什么 / 为谁 / 不做什么），本子步把这句摊开成决策表。没有这张表就去做取证，等于拿着自己的猜测去查资料，查回来的东西答的不是用户的问题。 + +## ⭐⭐ 合并后要覆盖两个火力点（分两节提问，⛔ 不许省略后半节） + +| 节 | 火力点 | 原归属 | 不做的后果 | +|---|---|---|---| +| **A 节** | **要做什么、为谁、边界在哪** | ①段 | 不澄清就没法取证 —— 查回来的答的不是用户的问题 | +| **B 节** | **做成什么样、哪些情况不成立、状态怎么流转** |②段| 不压测就没法写②段—— AI 带着理解错的需求一路做到原型 | + +> 合并的代价要先说清：两个火力点合到一处，提问量必然变大。 +> 解决办法是分节提问：先问完 A 节，再开 B 节；每节内部照旧一轮问完整个 frontier。 +> ⛔ 不许因为量大就把 B 节略过。B 节里没问清的状态与不成立条件，②段不会再有第二次机会（②段从 2026-10-06 起只细化功能，不再反问）。 + +## 核心规则 + +把需求当成决策树：每个决策分支出依赖它的决策。 + +按轮次（round）推进，不按单问推进。 + +frontier = 所有前置条件已定的决策，也就是现在就能问、不必先猜其他答案的那些问题。 + +一轮问完整个 frontier：逐条编号、每个都给出你的推荐答案，然后停下等用户回答，再据此重算 frontier 进入下一轮。 + +单轮格式： + +``` +❓ **Q1** - **<问题标题>**：<问题正文，可多段，含选项> + +➡️ <你的推荐答案> + +--- + +❓ **Q2** - **<问题标题>**：<问题正文，可多段，含选项> + +➡️ <你的推荐答案> +``` + +依赖必须排序：若某问题的答案依赖于本轮另一个尚未决断的问题，它属于下一轮，不属于本轮。 + +事实归你，决策归用户。需要外部事实（竞品现状、市场价格、技术可行性、法规）时，派 sub-agent 去查，不要问用户。也不要因此阻塞——只有下游问题等 sub-agent 回报，本轮其余问题照问不误。用户负责拍板，不负责查资料。 + +## 反问优先，模型可自动补全（本段的关键差别） + +默认动作是反问，不是替用户决定。每个问题都先抛给用户，并附上你的推荐答案与理由。用户看到选项才好拍板，光看问题会卡住。 + +允许自动补全，但要留痕。下列情况模型自己给出答案并继续推进，不阻塞： + +- 用户明确说"你定 / 不知道 / 先按你的来" +- 用户连续两轮未回应某个问题 +- 问题属于事实类，sub-agent 查得到（此时直接给结论，标 `【事实】`） + +自动补全的产出必须满足三条： + +1. 标 `【假设】`，并写清理由与「一旦不成立会有什么后果」 +2. 每轮结束把当前所有 `【假设】` 项汇成一份待复核清单，让用户一次性过，不静默塞进结论里 +3. 未经复核的 `【假设】`，在 1c 产品定位与场景里不得当作事实使用，也不得写进策略结论 + +自动补全不等于替用户拍板。它换的是「别卡住」，不是「别问」。用自动补全把问题糊过去，比不澄清更糟。 + +## 结束条件 + +frontier 为空 = 决策树每个分支都走过、没有静默假设，且待复核清单已被用户过了一遍。 + +用户始终不回应时，允许带着 `【假设】` 往下走，但要在 `1a-需求文档.md` 顶部写明「本表 X 项为模型假设，未经用户确认」，让下游一眼看到风险。 + +> 状态行不许只写好消息：顶部必须同时给出「已确认 N 项 / 模型补全 M 项（M 项未经用户确认）」两个数。「frontier 为空 / 无遗留未决项」不得单独出现。本项目实测踩过：状态行写「frontier 为空——12 项决策全部有来源」，同文件待复核清单里躺着 3 项未经用户逐条回应。 + +## 与 product-planning 的约束隔离（重要） + +`product-planning` 常规流程设有「提问上限 3 个」与「一次一段」。本子步不受这两条约束，把需求问清楚正是它的全部价值。 + +因此进入本子步时必须先显式告知用户「接下来会连续多轮提问，每轮若干编号问题，每个都附推荐答案」，退出后恢复常规约束。不声明就直接连问，会被当成跑偏。 + +## A 节必须覆盖的分支（要做什么、为谁、边界在哪） + +下表是需求决策树的一级分支，每个分支下再按依赖展开。 + +| 分支 | 要问清的 | +|---|---| +| 目标 | 解决什么问题、成功怎么衡量、谁最痛 | +| 用户 | 谁用、熟练度、在什么场景下用、现在怎么凑合 | +| 范围 | 第一版做什么、**明确不做什么**、什么东西不在这个产品里 | +| **交付形态** | **这套东西应该有几个界面 / 一页几件事 / 信息承载到哪一层 / 它长在哪（独立成页 or 嵌进已有产品的页面）**（2026-09-29 新增；2026-10-13 补第 4 问） | +| 素材与数据 | 手上已有什么（存量数据、素材、样例）、还缺什么才能验证 | +| 约束 | 预算 / 人力 / 时间 / 合规底线 | +| 依赖 | 依赖哪些外部系统、平台、第三方能力 | +| 竞品与替代 | 用户现在拿什么替代、为什么换（事实类可自动补全） | + +> ⭐ 为什么「交付形态」是必问支（实战教训）： +> 原有 7 个必问分支覆盖了「做什么、为谁、边界」，唯独没问「交付成一个什么样的东西」。本项目①段问完了范围却漏掉形态，③段于是把六件事塞进一个页面，做成 2,884 行、约 190 个交互函数的「控制台」，被用户判定为「最多算一个产品框图」。 +> +> 本支至少要问清四件事： +> | # | 问题 | 为什么在 ① 段问 | +> |---|---|---| +> | 1 | **价值主要在哪一层**——约定 / 文件结构，还是界面？ | 决定界面的**复杂度上限**。答"约定为主"则界面必须薄 | +> | 2 | **应该有几个界面**，每个界面只办一件事时的"一件事"是什么 | 结构性决策；**漏掉它，后续所有界面文档都要重做** | +> | 3 | **信息承载到哪一层**——哪些必须一进来就看到，哪些点一下能看到即可 | 决定"信息墙"是否发生（②段会据此出分档表） | +> | 4 | **它长在哪**——独立成页，还是嵌进已有产品的哪个位置；原有功能保留哪些 | 决定这是"新建一个界面"还是"往已有页加一块"。已有产品时，只答"一个界面"会被下游执行成**另起一页**，那一页的原有功能整块丢掉（2026-10-13 实测：某项目照此做，原有板块的功能在原型里出现次数全部为 0） | +> +> 不适用时：若产品确实没有界面（纯 CLI / 纯约定），在 `1a-需求文档.md` 写明「本产品无界面，交付形态=约定 + 脚本」，不留空、不跳过。 + +## B 节必须覆盖的分支（做成什么样、哪些情况不成立、状态怎么流转） + +> 这一节是 2026-10-06 从②段合并进来的。原②段的写法是「在 `create-prd` 之前做一次功能压测」，目的是把「需求澄清」从可跳过的步骤变成强制环节，避免 AI 带着理解错的需求把②段和原型一路做完。合并后目的不变，只是位置前移到这里。 + +| 分支 | 要问清的 | +|---|---| +| 形态与骨架 | 有哪几页、每页大致几个板块、板块怎么排、页与页怎么连（**粗粒度即可**，细的归②段的《界面布局》） | +| 不成立条件 | 什么情况下这套东西**不适用 / 用不起来**（不是"异常"，是"这个做法本身失效"） | +| 状态流转 | 有哪些状态、按什么次序触发、彼此怎么迁移（起始 / 中间 / 终态） | +| 失败与恢复 | 失败怎么办、能否重试、谁兜底 | +| 数据契约 | 输入什么、产出什么、谁来维护、存在哪 | +| 权限 | 谁能看、谁能改、越权怎么处理 | +| 并发与幂等 | 同一件事被做两次会怎样、多个人同时改会怎样 | + +> ⭐ B 节的产出落进 `1a-需求文档.md`。 +> ⭐ B 节问的是「做成什么样」，不问「做成什么样好看」：配色 / 字体 / 间距 / 动效一律不在这里问（那是③段）。 +> ⭐ B 节的「形态与骨架」是粗粒度：本轮只确认「有哪几页、大概几个板块」，精确的板块清单与布局图归②段。 +> ⛔ 不许在 B 节就把页面结构写死 —— 那会让②段的《界面布局》变成照抄。 + +## 必须落盘 + +全部轮次结束后，输出一张决策表写入 `docs/pm/<项目>/research/1a-需求文档.md`： + +| # | 问题 | 决策 | 来源 | 理由 | 影响范围 | +|---|---|---|---|---|---| +| Q1 | ... | ... | 用户拍板 / 【假设】 / 【事实】 | ... | 影响哪几份下游文档 | + +「来源」列是本表的关键，一眼看出哪些是用户拍的板、哪些是模型补的。1c 的每条结论都要能追到本表的某一行（或追到 1b 的某份调研文件）。 + +这张表是 1b（调研什么）与 1c（方案怎么定）的共同输入，也是②段写那两份文档的输入，不许与已定决策冲突。 + +## 反面清单 + +- 跳过本子步直接开调研，拿着自己的猜测去查资料 +- 一轮只问一个问题，浪费轮次 +- 问用户「你觉得竞品怎么做的」这类你本该自己查的事实 +- 把依赖未决答案的问题塞进本轮 +- 一轮抛几十个无编号、无推荐答案的问题，让用户无从下手 +- 不声明就开问，与 product-planning 的常规节奏冲突 +- 把自动补全当默认动作，用户没说话就替他决定，还不标 `【假设】` +- 标了 `【假设】` 却没进待复核清单，静默流进策略结论 +- 漏问「交付形态」这一支（2026-09-29 新增）：问完了「做什么、为谁、边界」，却没问「应该有几个界面、价值在哪一层」。后续 ②③ 段会在无形态依据的情况下自行发明结构，做出来的东西被判定为「产品框图」。该支为 A 节必问项 +- ⛔ 只问「应该有几个界面」不问「它长在哪」（2026-10-13 新增）：已有产品时，这两问**必须并列**答。只答"一个界面"⇒ 下游把它做成独立页，原有功能整块丢掉（实测：某项目就是这么丢掉整个原有板块的） +- ⛔ 只做 A 节、跳过 B 节（2026-10-06 新增）：B 节是从②段合并来的，跳过它等于把功能压测整个删掉，接口会带着没压测过的需求直接进②段与原型 +- ⛔ 在 B 节把页面结构写死（2026-10-06 新增）：B 节只给粗粒度形态；精确板块清单与布局归②段 +- ⛔ 状态行只写「frontier 为空」，把未经确认的模型补全藏在正文（2026-10-02 新增） + +## 附：输出检查 + +交付前逐条过。任一条为「否」，退回重跑。 + +- [ ] 起点那句（做什么 / 为谁 / 不做什么）已摊开成决策表，写入 `docs/pm/<项目>/research/1a-需求文档.md` +- [ ] A 节各分支都问过，其中「交付形态」支问清了「价值主要在哪一层 / 应该有几个界面 / 信息承载到哪一层 / 它长在哪（独立成页 or 嵌进已有产品的页面；原有功能保留哪些）」 +- [ ] B 节各分支都问过，状态与不成立条件没有遗漏 +- [ ] 每轮问题都有编号与推荐答案，依赖未决答案的问题没塞进本轮 +- [ ] 所有 `【假设】` 都进了待复核清单；状态行同时给出「已确认 N 项 / 模型补全 M 项（M 项未经用户确认）」，没有单写「frontier 为空」 +- [ ] 决策表的「来源」列逐行标了 用户拍板 / 【假设】 / 【事实】，1c 的每条结论都能追到某一行 diff --git a/product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/SKILL.md b/product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/SKILL.md new file mode 100644 index 0000000..80a63c3 --- /dev/null +++ b/product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/SKILL.md @@ -0,0 +1,186 @@ +--- +name: stage-proto-doc +description: 产品规划第④段，原型说明文档。在③段已跑通的原型 HTML 上补说明区，并产出一份能独立阅读的产品文档：按七节铺开 —— 原型页面地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值，编号用 P 页面／S 场景／F 功能／J 二级功能，起手复制段内模板 `assets/产品文档模板.html`。当用户要给原型加功能说明区、写产品文档、做操作指引演示，或说「只做原型说明文档」时调用。 +--- + +# ④ 原型说明文档 + +## 定位 + +- 本段解释和记录**现有**原型：不重新规划产品，不重新设计界面。 +- 交付两份产物：原型内嵌说明区、可独立发送的产品文档。两份共用同一套编号、场景、流程与功能定义。 +- 原型是界面行为的核对依据；①段的决策表与②段的功能清单是业务意图的补充依据。 +- 两份产物都按**七节**组织（原型页面地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值），骨架与 `assets/产品文档模板.html` 同构；⛔ 不按状态轴分段，也不把原型的界面状态当成文档的层级（界面状态只在第七节里写）。 +- 说明区是注解层，不是产品功能。交付时明说，免得让人以为产品里真有一个说明页。 + +## 输入 + +| 来自 | 读什么 | 用来定什么 | +|---|---|---| +| ③ | `designs/<项目>/*.html` | 界面事实的唯一依据：页面、模块、控件、状态、交互、跳转、反馈 | +| ② | `docs/pm/<项目>/prd/2a-产品功能.md` · `docs/pm/<项目>/prd/2b-界面布局.md` | 术语口径、优先级、功能条目编号 | +| ① | `docs/pm/<项目>/research/1a-需求文档.md` | 需求来源与「不做什么」的边界 | + +- 原型是界面事实，需求资料只定业务意图；两者冲突时显式记录，不静默选一个。 +- **上游缺失时**：先把缺的那一段补出来（②段缺失就先要一份最小术语表）；用户不要补，就在文档里逐处标 `【假设】`，并在段末的偏离单里写明「本段未判术语一致」。 +- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来停下问用户，不猜。 + +顺序 4a → 4b → 4c。说明区先齐，再放演示引导。 + +## 4a 场景盘点（必做，最先） + +读 `references/doc-area-spec.md`。产出：页面清单（`P`）＋ 使用场景清单（`S`）＋ 功能清单（`F`）＋ 二级功能（`J`），编号先占好、各自全篇唯一并按展示顺序通排。 + +## 4b 说明区（两份产物） + +读 `references/doc-area-spec.md` 铺框架，读 `references/doc-language-spec.md` 定语言：两份产物写完后，逐句过它第五节的自检清单。 + +**产物 A · 原型内嵌说明区** + +- 写进原型 HTML 自身，不依赖外链。 +- 放在原型对应位置的下方，随当前所在的那一段一起变。 +- 含原型页面地址、页面结构、功能清单、使用场景、操作流程、页面导航、原型状态取值七节。 +- 不覆盖业务区域，不改既有交互逻辑；原型结构不适合直接嵌入时，给可插入的 HTML 片段与插入位置。 + +**产物 B · 独立产品文档** + +- 单独一个 HTML 文件，落 `designs/<项目>/<产品项目名>.html`（**文件名＝产品项目名**），双击能开，能单独发给不看原型的人。 +- ⭐ **起手先复制通用模板**：`assets/产品文档模板.html`（本段自带）。它已经定好七节骨架、页面地址清单、页面结构图、功能清单（含目标产品特有列）、场景表、横向流程图、页面导航、状态取值表；把 `<尖括号>` 占位逐个换成真实内容即可，⛔ 不要从空白页重写结构。 +- 模板里定死的口径，照着填：编号 P／S／F／J 各自全篇唯一并按展示顺序通排；功能区命名用用户的叫法；流程画成**横向**流程图且每步写清「页面／功能／操作／完成判据」，「操作」行用强调色；重点功能在功能名、说明、目标产品特有列三处同时标红。 +- 七节顺序固定，与模板同构（见下面「产品文档框架」一节）。 + +## 4c 演示引导（可选） + +读 `references/guided-tour.md`，给每条流程放「演示」按钮。**用户不要演示时整体跳过**，跳过就在段末写明「本段未做演示引导」，完成标准里对应的那几条一并免检。 + +## 产品文档框架（七节 · 与 `assets/产品文档模板.html` 同构） + +⭐ **起手先复制通用模板** `assets/产品文档模板.html`（本段自带）：它已定好七节骨架、页面地址清单、页面结构图、功能清单（含目标产品特有列）、二级功能表、使用场景表、横向流程图、页面导航、状态取值表；把 `<尖括号>` 占位逐个换成真实内容即可，⛔ 不要从空白页重写结构。 +模板里定死的口径照着填：编号 `P`／`S`／`F`／`J` 各自全篇唯一并按展示顺序通排；功能区命名用原型界面上的叫法；流程画成**横向**流程图；重点功能在功能名、说明、目标产品特有列三处同时标红。 + +### 一、原型页面地址 + +- 每个原型页一行相对链接：文件名 ＋ 一句它是什么；放在文档最前。 +- ⛔ 不写本机绝对路径，⛔ 不写说明句 —— 读者直接点开就行。 + +### 二、页面结构 + +- 给一张页面结构图，图上标出各页面与其下的功能编号（页面 `P00x`／功能 `F00x`）。 +- 页面层级写一级／二级；功能区命名用原型界面上的叫法。 + +### 三、功能清单（表格） + +列：序号／页面名称／层级／功能区／功能（`F00x` ＋ 名称）／功能做什么／功能细节／目标产品特有列（本项目＝租户列）／待开发。 + +- 一行 = 一项功能；功能名与原型界面上的叫法一致。 +- 重点功能在功能名、说明、目标产品特有列三处同时标红，并在「重点项」表里补一行（重点项／说明／相关编号）。 +- 二级功能（一项功能展开的多个选项）另起一张表：编号 `J001`…／二级功能项／产出什么／对应页面功能。 +- 模板列之外，每项功能还要补齐这四项才算写完： + **做什么** —— 写处理行为与可观察结果，不写功能口号。 + **入口在哪** —— 给到可定位的页面与控件。 + **输入边界** —— 覆盖输入类型、必填、格式、长度、范围；无输入的功能写「无用户输入」。 + **异常与恢复** —— 写异常触发条件、界面反馈、恢复操作；原型没体现就写「原型未体现」，不写成已实现。 + +### 四、使用场景 + +- 一行 = 一个场景，写「用户要办成的一件事」，不写模块名；编号 `S001`…。 +- 每条带 前提／目标／原型位置（写到「页面 → 模块 → 控件或状态」，能在原型上点到）。 +- 场景后标该场景下的条目数。 + +### 五、操作流程（横向流程图） + +- 每个场景一条横向流程图，每步写清 页面／功能／操作／完成判据，「操作」行用强调色。 +- 步骤链 2–6 步；起点满足场景前提，终点对应场景目标。 +- 步骤里的按钮、菜单、字段、状态名称与原型逐字一致；流程里不出现原型没有、也没确认过的操作。 + +### 六、页面导航 + +- 一条导航一段，写成「来源页 → 目标页」＋走法；单向跳转与打开方式一并写明。 +- 原型没体现的跳转写「原型未体现」，不写成已实现。 + +### 七、原型状态取值 + +- 一行一个取值，写清取什么值落在哪个界面。 +- 取值与状态名一律以原型为准；⛔ 不把页面层级当状态写。（已验证过 `?state=` 这类取值清单的界面，走这条；无此机制的原型写「无」） + +## 编号与关联 + +- 页面 `P001`…、使用场景 `S001`…、功能 `F001`…、二级功能 `J001`… —— 各自全篇唯一、按展示顺序通排。 +- 同一场景、同一功能在不同章节重复出现时复用同一编号。 +- 每项功能至少挂在一个页面（`P00x`）上，挂不上就标「未映射」。 +- 二级功能 `J00x` 必须标出它对应的 `F00x`。 +- 功能可以服务多个场景；多对多时逐项列出关联编号。 +- 页面、模块、控件的数量不等于功能数量。 + +## 语体口径 + +- **完整规范读 `references/doc-language-spec.md`**：术语来源优先级、逐条禁用清单、五组对错对照、以及一份逐句自检清单。写每一句都照它过，自检任一项不通过就改。 +- 元信息（条数、口径、读法）写进表格的列、条目的字段或表头里；标题后面与标题下面都不另起说明行（踩过的坑：在标题下用小字解释「这一节是什么、为什么这么排」，2026-10-14 用户第三次点名，前两次分别是原型的状态小字与章节注解）。 +- 客观、书面的说明文，一句话只表达一个主要意思。 +- 用确切的页面名、模块名、控件名、状态名与业务术语；同一个概念全篇同名。 +- 描述行为用可验证的动词：显示、输入、选择、提交、生成、跳转。 +- 区分「已实现／未实现／待确认」三种状态，各写各的。 +- **禁用清单**：营销话术、主观评价、模糊程度词（大概、尽量、适当）、无依据的效果承诺、「相关页面／适当提示／处理异常」这类无法定位的说法、第一人称、比喻、空转评价（「值得注意的是」「具有重要意义」）。 +- 缺失信息明确标记，不用推测性描述填空白。规则文件本身也用这套语体写。 + +## 硬约束 + +- 只用原型上真实存在的事实；每条说明都能在原型上指到对应元素。 +- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。 +- 不擅自新增页面、功能、需求、业务规则或交互。 +- 把静态展示与真实数据处理能力分开写；把模拟数据、模拟提交、演示反馈与真实后端能力分开写。 +- 把计划实现与已实现分开写。 +- 不遗漏编号，不重复分配编号。 +- 两份产物的名称、编号、范围、入口、行为描述必须一致。 +- 说明区不依赖外链，不破坏原型原有功能。 +- 原型与需求资料的差异显式记录。 +- 自动结论不写成人工认可：机器判定只能说「进入队列／待人工逐条查看」，不写成「通过／已认可」。 +- 段内不反问，做完直接进下一个子步；停线规则见 `product-planning` 的「执行规则」。 +- 原型是生成物时，改动走它自己的生成链，不手改产物。 +- ⭐ 文档前面必须配图（2026-10-15 用户令）：本段落盘的每份文档，正文（第一张表 / 第一小节）之前必须先给一张图 —— 本段画《页面结构图 ＋ 用户路径图》；用 `diagram-design` 画，⛔ 手写 Mermaid。图是正文内容，⛔ 不写成标题旁边或标题下面的注解小字。 + +## 完成标准 + +- 独立产品文档含规定的七节，顺序固定，双击能开（起手用 `assets/产品文档模板.html`）。 +- 原型内嵌说明区能在原型里直接找到并读到。 +- 每条使用场景有唯一编号 `S00x`，并带前提、目标、原型位置。 +- 每条场景至少一条横向流程，每条 2–6 步且能在原型中逐项核对；在原型上点不出结果的场景标 `funcOnly`（只写进功能清单、不画流程），并在段末待确认清单里写明为什么点不出来。 +- 每项功能的 做什么／入口在哪／输入边界／异常与恢复 都填了（编号 `F00x`）；二级功能标出对应的 `F00x`。 +- 引用的编号都存在，页面／场景／功能／二级功能四类各自唯一且按展示顺序通排。 +- 两份产物没有互相矛盾的描述。 +- 未确认事项都有标记，并在段末列出待确认清单。 +- 原型原有页面与交互通过回归检查。 +- ⭐ 独立产品文档前面配了页面结构图（用 `diagram-design`，⛔ 无手写 Mermaid） + +## 自查清单 + +- [ ] 输入原型能运行、关键交互能走完 +- [ ] 实际实现／模拟行为／待确认三者的界线划清了 +- [ ] 独立产品文档按七节顺序排好，起手用了 `assets/产品文档模板.html` +- [ ] 页面结构图已配（用 `diagram-design`，⛔ 无手写 Mermaid） +- [ ] 页面 `P00x`／场景 `S00x`／功能 `F00x`／二级功能 `J00x` 各自唯一且按展示顺序通排 +- [ ] 每条场景有前提、目标、原型位置 +- [ ] 每个场景一条横向流程，每条 2–6 步，每步写清页面／功能／操作／完成判据 +- [ ] 每项功能的 做什么／入口／输入边界／异常与恢复 都填了 +- [ ] 重点功能在功能名、说明、目标产品特有列三处同时标红 +- [ ] 二级功能都标了对应的 `F00x` +- [ ] 界面名称与原型逐字一致 +- [ ] 失效编号、孤立功能、未映射功能已清理 +- [ ] 两份产物同一套定义、可相互核对 +- [ ] 说明区没破坏原型运行 +- [ ] 上游缺失处已标 `【假设】` 并写进偏离单 +- [ ] 未做演示引导时已写明并免检对应条目 + +## 反面清单 + +- 只写页面介绍，不写需求、场景、流程和功能 +- 用功能模块代替需求，需求条数没法统计 +- 用「用户使用系统」这类泛化描述代替具体场景 +- 用「点击按钮后完成操作」代替可核对的步骤与结果 +- 用「支持多种格式」代替明确的输入边界或待确认标记 +- 用「发生错误时提示用户」代替异常条件、反馈和恢复路径 +- 把原型里的静态假数据写成真实业务数据 +- 把未实现、未验证、未定义的行为写成既有能力 +- 两份产物里功能名称、编号或流程对不上 +- 改原型业务逻辑去迎合文档描述 +- 以篇幅、术语数量或排版代替可验证的完整性 diff --git a/product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/assets/产品文档模板.html b/product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/assets/产品文档模板.html new file mode 100644 index 0000000..539f915 --- /dev/null +++ b/product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/assets/产品文档模板.html @@ -0,0 +1,255 @@ + + + + +产品文档模板 + + + +
+ +

<产品名> · 产品文档

+ +

+ 用法：把带 <尖括号> 的占位全部换成真实内容，删掉本节上面的示例行， + 再按第④段要求逐节填。编号口径：页面 P001…／使用场景 S001…／功能 F001…／二级功能 J001…，各自全篇唯一、按展示顺序通排。 +

+ +

一、原型页面地址

+ +

每个原型页一行相对链接（文件名 ＋ 一句它是什么），放文档最前；⛔ 不写本机绝对路径，⛔ 不写说明句 —— 读者直接点开就行。

+ +

二、页面结构

+

先给一张结构图，再列功能。页面框里按**功能区**分块，每个功能区画成自己的板块盒；连线只画真实存在的跳转，并在标签上写清触发动作。

+ + + + + + + + + + + + 入口：<从哪个页面> → <点什么> → <进到哪> + + <页面 A> + <一级页面> + + + <功能区名> + F001 <功能名> + F002 <功能名> + + + <页面 B> + <二级页面> + + + <功能区名> + F003 <功能名> + F004 <功能名> + + + <页面 C> + <独立页面> + + + <功能区名> + F005 <功能名> + + <触发动作> + + + <退回动作> + <触发动作> + + + + +

三、功能清单

+ +

页面功能

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
序号页面名称层级功能区功能功能做什么租户待开发
P001<页面 A><一级页面><功能区名>F001 <功能名><一句话说清它做什么、有什么限制>全部租户✓
<功能区名>F002 <重点功能名><重点功能用红字标出>麦芽租户✓
P002<页面 B><二级页面><功能区名>F003 <功能名><一句话说清它做什么>全部租户✓
<功能区名><待确认><待确认>全部租户✓
+

页面上每一项都要有 F00x 编号；页面序号／页面名称／层级合并格，功能区按区合并格；暂时没登记到功能的板块照样占一行，两格写「待确认」。

+ +

<二级功能名>（二级功能）

+

技能、模板这类**选项值**属于二级功能：它们由页面功能 <F00x 功能名> 承载，在这里**引用**那个页面功能，自己不再占 F 编号。

+ + + + + + +
序号二级功能项产出什么对应页面功能
J001<选项一><产出什么><F00x 功能名>
J002<选项二><产出什么><F00x 功能名>
+ +

重点说明

+ + + + + + +
重点项说明相关编号
<重点项一><为什么是重点、它覆盖哪些能力><F00x、F00x>
<重点项二><为什么是重点><F00x>
+

上述功能为本次新增功能。

+ +

四、使用场景

+ + + + + + + + + + + + + +
序号场景含几条流程优先级待开发对应功能
S001<用户要办成的一件事><N> 条P0✓<功能名（F00x）>、<功能名（F00x）>
S002<用户要办成的另一件事><N> 条P0✓<功能名（F00x）>
+

共 <N> 条使用场景，含 <N> 条流程、<N> 个操作步骤。

+

判定口径：用户通过产品功能办成、且**拿到一个结果**的才叫一件事；起手、分支、异常、同一件事的两种手法都并回所属那件事。拿不到结果的（进到某个页面、确定某个取值）不列为场景，只作功能步骤。

+ +

五、操作流程

+

每条流程画成一张**横向**流程图：步骤盒自左向右排、箭头横向连接；每个盒自带标题栏（只放步骤名），正文写页面／功能／操作／完成判据；**「操作」那行用强调色**。

+ +
+

S001　<场景名>

+

<这条场景是在什么前提下、办成什么事>

+ +
流程 1　<流程名>
+ + + + + + + + + + 1. <步骤名> + 页面：<页面名> + 功能：<F00x 功能名> + 操作：<这一步怎么操作> + <操作的续行> + 完成判据：<界面停在哪个状态> + + + + 2. <步骤名> + 页面：<页面名> + 功能：<F00x 功能名> + 操作：<这一步怎么操作> + 完成判据：<界面停在哪个状态> + + + + 3. <步骤名> + 页面：<页面名> + 功能：<F00x 功能名> + 操作：<这一步怎么操作> + 完成判据：<本件事最后一步> + + + + + + +
流程 2　<另一条流程（异常／等待等）>
+

同一件事下的分支、加载中、失败，都作为这条场景的**另一条流程**，不另起一节。

+
+ +

六、页面导航

+

<来源页> → <目标页>：<走法>。

+

<来源页> → <目标页>：<走法>。

+

<来源页> → <目标页>：<走法>；<单向跳转与打开方式>。

+

一条导航一段，标签写「来源页 → 目标页」，正文写走法；⛔ 不在这里写界面状态 —— 那归第七节。

+ +

七、原型状态取值

+

<界面状态用地址后的哪个参数指定；不带参数时落在哪个界面>。

+ + + + + + +
取值界面
<取值一><落在哪个界面>
<取值二><落在哪个界面>
+

取值与状态名一律以原型为准；⛔ 不把页面层级当状态写。原型没有这套机制时，整节写「无」。

+ +
+ + diff --git a/product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/references/doc-area-spec.md b/product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/references/doc-area-spec.md new file mode 100644 index 0000000..3299bc2 --- /dev/null +++ b/product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/references/doc-area-spec.md @@ -0,0 +1,73 @@ +# 原型说明区规范 + +> 本文件是 `stage-proto-doc` 的方法论文档，由模型按需加载，没有斜杠命令。 +> 骨架与 `assets/产品文档模板.html` 同构 —— 说明区就是独立产品文档的七节，嵌进原型对应位置。两份产物共用同一套编号、场景、流程与功能定义。 + +## 定位 + +说明区是原型自带的注解层，不是产品功能。它不回答"长什么样"，回答的是： + +> 站在这个界面上，我这一步在干什么、我能输入什么、什么情况下它不给好脸色。 + +所以它贴在原型对应位置的下方，随当前所在的页面一起变。抽出来单独写一份，读者就得自己脑补对应关系。 + +## 七节怎么落进原型 + +- **一、原型页面地址**：每个原型页一行相对链接（文件名 ＋ 一句它是什么），放在文档最前；⛔ 不写本机绝对路径、⛔ 不写说明句。 +- **二、页面结构**：页面结构图放原型首页顶部，图上标出各页面与其下的功能编号（页面 `P00x`／功能 `F00x`）。 +- **三、功能清单**：表格贴在对应功能区下方 —— 列：编号／页面／层级／功能区／功能（`F00x` ＋ 名称）／功能做什么／功能细节／目标产品特有列（本项目＝租户列）／待开发；二级功能另起一张表（`J00x`／二级功能项／产出什么／对应页面功能）。重点功能在功能名、说明、目标产品特有列三处同时标红。 +- **四、使用场景**：每个场景一段，带前提／目标／原型位置（写到「页面 → 模块 → 控件或状态」，能在原型上点到）。 +- **五、操作流程**：每个场景一条横向流程图，规则见下节。 +- **六、页面导航**：一条导航一段，写成「来源页 → 目标页」＋走法；单向跳转与打开方式写明。 +- **七、原型状态取值**：一行一个取值，写清取什么值落在哪个界面；取值与状态名以原型为准。 + +## 场景怎么写 + +- 粒度是"人要完成的一件事"，不是一个按钮。"提交驳回"不算场景，"驳回一条片段并完成失败模式归类"才算。 +- 一个页面下的场景数控制在 2–4 个。1 个说明不了分支，5 个以上就该拆页面或拆功能区。 +- 顺序按发生频率排，不按界面从上到下排。 +- 前提一句话写清。例："预审排队、执行中或失败时人工仍可决策，但必须清楚自己在无依据的情况下决策。" + +## 横向流程图 + +| 规则 | 说明 | +|---|---| +| 形态 | 横向 `ol`，每项 = 序号圆点 + 步骤名，项间一个 `→` 箭头 | +| 每步内容 | 写清 页面／功能／操作／完成判据，「操作」行用强调色 | +| 溢出 | 横向滚动，不换行 —— 换行会读成两条并行流程 | +| 步数 | 2–6 步：超过 6 步说明这个场景该拆，1 步说明它还不算流程 | +| 交互 | 点步骤 → 下方出这一步的四项说明；再点收起；同级只选中一个 | +| 键盘 | 步骤是 `button`；`aria-current` 标当前项；说明区 `role="region"` 带 `aria-controls` | +| 箭头 | `aria-hidden`，它只是视觉连接符，不进朗读 | + +## 每项功能的四项要求 + +| 项 | 回答的问题 | 合格判据 | 不合格示例 | +|---|---|---|---| +| 做什么 | 这一步做什么、给谁看、落笔后产生什么 | 换一个组件这句话就不成立 | "展示相关信息，提升审核效率" | +| 入口在哪 | 可定位的页面与控件 | 能在原型上点到 | "相关入口" | +| 输入边界 | 取值域 / 上限 / 前置条件 / 必填与选填 | 说得出"什么不被接受"或"最多几条" | "支持筛选" | +| 异常与恢复 | 失败 / 空 / 禁用 / 重复提交 / 恢复路径 / 文案红线 | 至少一种"坏了怎么办"，且给出出路 | "暂不支持" | + +写输入边界，常见切入点：数量上限、字数或时长范围、哪些状态才可用、必填项有哪些、一次作用于一条还是全部。 + +写异常与恢复，常见切入点：加载中能不能点、失败了怎么重试、重复提交怎么挡、空的时候显示什么、禁用要不要给原因、文案不能写成什么。 + +### 文案红线 + +- 不得把自动结论表述为人工认可。机器判定只能说"进入队列 / 待人工逐条查看"，不写成"通过 / 已认可 / 已确认"。 +- 不用无法区分成因的笼统文案。"暂无数据"要拆成"批次为空"与"筛选无结果"两条出路。 +- 不承诺原型里点不出来的能力。说明区每条都要能在原型上指到对应元素。 +- 异常态必须给恢复路径。只写"失败了"不算说明，要写清楚下一步按哪里。 + +## 自查（逐条打勾） + +- [ ] 七节都落到原型对应位置，顺序与模板一致 +- [ ] 页面 `P`／场景 `S`／功能 `F`／二级功能 `J` 各自唯一且按展示顺序通排 +- [ ] 每个场景 2–6 步，每步写清页面／功能／操作／完成判据 +- [ ] 每项功能的四项都填了，且各自能通过上面的合格判据 +- [ ] 重点功能在功能名、说明、目标产品特有列三处同时标红 +- [ ] 全文没有"通过 / 已认可"这类把机器结论说成人审的词 +- [ ] 每个禁用态都给了原因，每个异常态都给了恢复路径 +- [ ] 说明区文案与②段术语逐词一致 +- [ ] 点不出结果的场景已标 `funcOnly`，并在段末待确认清单里写明为什么点不出来 diff --git a/product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/references/doc-language-spec.md b/product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/references/doc-language-spec.md new file mode 100644 index 0000000..0b6dd10 --- /dev/null +++ b/product-planning/references/_留痕/N7-返工-20261016/references/stage-proto-doc/references/doc-language-spec.md @@ -0,0 +1,322 @@ +# 产品文档语言规范 + +> 来源：ChatGPT 网页版（2026-10-14，会话 `6acf7fc1-8d10-83e8-b328-8e885f5efb8c`）。 +> 用法：写④段的两份产物时逐句过一遍；第五节自检清单任一项不通过就改。 +> 它管**语言**；文档骨架（七节：原型页面地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值）见上一级 `SKILL.md`。 + +--- + +## 一、语体与句式 +### 1.1 语体要求 + +使用客观、正式、书面的说明文语体。 + +面向产品、开发、设计人员，确保读者不查看原型也能理解文档内容。 + +描述系统行为时使用可验证的事实，不使用主观评价或个人感受。 + +区分已实现行为、计划行为、未实现行为和待确认事项。 + +不使用聊天式表达、营销式表达、口号式表达或未经证实的效果承诺。 + +### 1.2 句式要求 + +一句话只表达一个主要意思。 + +一个句子只描述一个主要动作、判断、规则或结果。 + +存在多个独立动作时，拆分为多个句子，并按执行顺序排列。 + +存在条件关系时，明确写出条件和对应结果。 + +存在因果关系时，明确写出原因和结果，不使用含糊的连接词。 + +描述操作时，优先使用「操作主体＋动作＋对象＋结果」句式。 + +描述规则时，优先使用「适用条件＋处理规则＋预期结果」句式。 + +描述异常时，明确异常条件、系统反馈和恢复方式。 + +删除不影响事实含义的铺垫、重复解释和语气修饰。 + +不得为了追求简短而省略执行主体、操作对象、条件或结果。 + +### 1.3 句子验收标准 + +一个句子包含两个及以上可独立执行的动作时，拆句。 + +一个句子包含两个及以上独立判断条件时，按规则复杂度拆分或使用列表。 + +句子出现代词时，必须能够从当前句或明确的上下文唯一确定指代对象。 + +句子出现条件时，必须能够判断条件成立与不成立时的处理方式。 + +句子描述完成状态时，必须给出可观察或可判断的完成标志。 + +## 二、名词与术语 +### 2.1 术语来源优先级 + +按以下顺序确定文档中的术语： + +原型界面上实际显示的页面名、模块名、按钮名、字段名和状态名。 + +已确认的产品需求、功能定义及业务术语表。 + +行业内含义明确且与当前业务一致的通用术语。 + +无法从以上来源确认的术语，标记为「待确认」，不得自行创造。 + +### 2.2 界面名称使用规则 + +界面已有名称时，文档必须使用原名称，不得随意改写、缩写或替换同义词。 + +首次提及界面元素时，使用完整名称。 + +同一对象在全文中必须使用同一名称。 + +页面名、模块名、控件名、字段名和状态名不得混用。 + +界面名称与业务概念不一致时，分别说明界面名称和业务概念，不得强行合并。 + +原型中没有名称的元素，不得擅自赋予正式名称；必要时使用位置描述并标记「待命名」。 + +引用按钮、菜单、字段或状态时，使用其实际显示文本，并通过引号或上下文明确其为界面名称。 + +### 2.3 新术语与未知术语处理 + +新术语必须有明确的业务定义、使用范围和来源。 + +同一概念存在多个叫法时，确定一个标准名称，其余叫法仅在必要时作为别名说明。 + +不得通过拼接常见词语创造未经定义的产品术语。 + +不得将技术实现名称直接当作用户可见的功能名称，除非产品资料明确采用该名称。 + +不得把个人理解、推测或临时命名写成已确认的业务定义。 + +无法确认术语含义时，记录待确认事项，不得通过上下文猜测后直接定稿。 + +### 2.4 指代与缩写 + +不使用指向不明确的「它」「这个」「相关内容」「上述功能」。 + +可以唯一定位对象时，直接使用对象名称。 + +缩写首次出现时，应给出中文全称及必要的英文全称。 + +缩写在全文中必须保持一致，不得交替使用全称、简称和自造简称造成歧义。 + +## 三、禁用清单 + +以下词语和句式在正式产品文档中一律禁用。确需表达对应含义时，必须替换为明确、可验证的描述。 + +### 3.1 聊天式表达 + +「我们可以……」 + +「你可以……」 + +「用户只要……就行」 + +「点一下……」 + +「然后就……」 + +「这个地方……」 + +「这里的话……」 + +「其实就是……」 + +「简单来说……」 + +「大概是……」 + +「差不多……」 + +「之类的……」 + +「等等」「诸如此类」 + +### 3.2 空泛动词与模糊表达 + +「搞定」「弄好」「处理一下」 + +「做一下」「操作一下」「配置一下」 + +「支持相关操作」 + +「进行相应处理」 + +「展示相关信息」 + +「提供便捷能力」 + +「实现快速处理」 + +「优化体验」 + +「提升效率」 + +「满足用户需求」 + +「智能处理」「自动优化」——未明确处理规则时禁用。 + +「实时更新」「快速响应」——未定义时效或判定标准时禁用。 + +「灵活配置」「多种方式」「丰富内容」——未列出具体范围时禁用。 + +### 3.3 无明确依据的程度词 + +「非常」「特别」「极其」 + +「十分方便」「十分简单」 + +「更加友好」「更加完善」 + +「高效」「便捷」「流畅」 + +「强大」「先进」「全面」 + +「无缝」「极致」「完美」 + +「大幅提升」「显著改善」 + +「一键完成」「秒级完成」——未验证对应行为或性能时禁用。 + +### 3.4 含糊的指代与范围词 + +「相关页面」「对应位置」——未给出具体名称或路径时禁用。 + +「相应内容」「相关信息」——未说明具体对象时禁用。 + +「适当提示」「必要时处理」——未定义触发条件时禁用。 + +「部分数据」「一些情况」「某些用户」——未限定范围时禁用。 + +「正常情况下」「特殊情况下」——未定义条件时禁用。 + +「根据实际情况」「视情况而定」——未说明判断规则时禁用。 + +「等」「等等」——用于省略必要枚举项时禁用。 + +### 3.5 空泛承诺与无依据结论 + +「确保用户满意」 + +「保证数据准确」 + +「避免所有错误」 + +「全面覆盖用户场景」 + +「系统会自动处理所有问题」 + +「用户能够轻松完成全部操作」 + +「该功能已经成熟稳定」 + +「该设计符合所有用户习惯」 + +以上表述只有在具备明确的验证依据、适用范围和判定标准时，才可以改写为具体的事实或约束。 + +### 3.6 不合格句式 + +「用户进入页面后，可以看到很多信息。」 + +「系统会根据情况进行相应处理。」 + +「用户点击按钮，然后系统就会完成操作。」 + +「如果有问题，系统会给出提示。」 + +「该功能主要用于提升用户体验。」 + +「支持多种输入方式，满足不同用户需求。」 + +「出现异常时，用户可以自行处理。」 + +「页面包含账号、内容、数据等相关模块。」 + +这些句式缺少具体对象、条件、行为、结果或处理规则，不得直接用于正式文档。 + +## 四、对错对照 +### 第 1 组：操作说明 + +不规范： 用户点一下提交按钮，然后就可以完成创建。 + +规范： 用户点击「提交」按钮后，系统校验表单必填项。校验通过时，系统创建记录并显示提交结果。 + +### 第 2 组：页面说明 + +不规范： 这里可以看到账号的各种信息，方便用户进行管理。 + +规范： 「账号列表」显示账号名称、所属平台、运营状态和最近更新时间。用户可通过列表操作入口查看账号详情。 + +### 第 3 组：输入规则 + +不规范： 用户填写相关信息就行，格式不对的话系统会提示。 + +规范： 用户必须填写「账号名称」字段。字段长度限制及允许字符范围为待确认。输入校验失败时的提示文案和恢复方式为待确认。 + +### 第 4 组：异常处理 + +不规范： 如果操作失败，系统会进行相应处理，用户重新试一下即可。 + +规范： 操作失败时，系统应显示失败原因和可执行的恢复操作。失败提示、重试条件及数据保留规则尚未确认。 + +### 第 5 组：功能价值 + +不规范： 该功能可以帮助运营人员高效地管理内容，提升工作效率。 + +规范： 「内容列表」集中显示内容标题、发布平台、审核状态和计划发布时间。运营人员可在列表中筛选内容，并进入详情页查看单条内容。 + +## 五、自检清单 + +每句话必须逐项检查。任一项不通过，必须修改后再提交。 + +语体检查： 是否存在聊天用语、口号、营销话术或主观评价？存在即不通过。 + +单义检查： 一个句子是否包含多个可独立执行的动作或多个独立结论？存在且未清晰拆分时不通过。 + +对象检查： 是否能明确指出句子描述的用户、系统、页面、控件、数据或业务对象？不能明确指出时不通过。 + +术语检查： 页面名、模块名、控件名和状态名是否与原型一致？不一致且未经说明时不通过。 + +来源检查： 是否出现没有来源、没有定义或未经确认的术语？存在且未标记时不通过。 + +动作检查： 是否明确写出发生了什么操作或系统行为？仅写「处理」「支持」「实现」而没有具体行为时不通过。 + +条件检查： 是否存在「如果」「当」「在……情况下」等条件表达，却没有说明对应结果？存在即不通过。 + +结果检查： 是否声称操作完成，却没有可观察的结果或完成标志？存在即不通过。 + +边界检查： 是否使用「多种」「部分」「适当」「相关」等词，却没有给出具体范围？存在即不通过。 + +事实检查： 是否将模拟行为、计划能力或未验证规则写成已实现事实？存在即不通过。 + +异常检查： 是否只写「提示用户」或「进行处理」，没有明确异常条件和恢复路径？存在即不通过。 + +独立阅读检查： 不查看原型的产品、开发和设计人员，是否能根据描述定位对象并理解行为？不能时不通过。 + +一致性检查： 同一对象在全文中是否存在多个未经定义的名称？存在即不通过。 + +精简检查： 删除某个词句后，事实、条件、动作或结果是否完全不受影响？若不受影响，应删除该词句。 + +## 六、最终验收规则 + +文档中的每句话都必须通过第五节自检。 + +所有界面名称必须有原型或已确认资料作为依据。 + +所有业务规则必须有明确来源；无来源的规则标记为「待确认」。 + +所有操作说明必须明确操作对象和可观察结果。 + +所有异常说明必须明确触发条件、反馈和恢复方式；尚未定义的内容标记为「待确认」。 + +禁用清单中的表达不得直接出现在正式说明正文中，必要的引用、规则举例和本规范自身的说明除外。 + +任何无法判断真假的描述均不得作为已确认事实写入文档。 + +文档以准确、可定位、可验证、可独立阅读为合格标准，不以篇幅或修辞作为质量标准。 diff --git a/product-planning/references/_留痕/N7-返工-20261016/references/stage-requirements/SKILL.md b/product-planning/references/_留痕/N7-返工-20261016/references/stage-requirements/SKILL.md new file mode 100644 index 0000000..9cf0586 --- /dev/null +++ b/product-planning/references/_留痕/N7-返工-20261016/references/stage-requirements/SKILL.md @@ -0,0 +1,198 @@ +--- +name: stage-requirements +description: 产品规划第②段，产品功能。只做一件事：把①段《使用场景》（`1e-使用场景.md`）细化成功能清单（做哪些 / 不做哪些 / 优先级），并钉死页面骨架（《界面布局》：有哪几页、每页几个板块、板块怎么排、跨页关系）。当用户要写②段两份、列产品功能、定优先级、梳理功能、定页面与板块布局，或说"只做产品功能"时调用。 +--- + +# ② 产品功能 + +回答「要做哪些产品功能、哪些明确不做、页面骨架怎么排」。产出两份： +`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单）＋ `docs/pm/<项目>/prd/2b-界面布局.md`（页面骨架）。 + +> 段名与①「产品需求」构成 `产品需求 → 产品功能 → 界面交互 → 原型说明` 的对称链，四段各占一个词（产品 / 功能 / 界面 / 说明），无一词共用（2026-10-02 用户定）。旧名「需求与结构」「界面与交付」已废。 +> +> 与①段的分界：①回答「要解决什么问题、用户怎么用它」，②回答「要做哪些功能、长成什么骨架」。判据看文档主体 —— 主体是功能条目的有无与优先级、页面与板块骨架，归②；主体是问题、用户、取证与取舍理由，归①。 +> +> ⭐ 2026-10-06 用户定案：本段收窄为「只细化功能」。2026-10-07 用户定案「2 产品功能 和 界面布局不就是两个文档嘛」，两件事各成一份：产品功能（做什么）＋ 界面布局（长什么样）。（①段侧的定案原话与 grill 归属见 `stage-discovery`，本段不复述。） +> +> 本段就这两份：`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单）＋ `docs/pm/<项目>/prd/2b-界面布局.md`（页面骨架）。 +> +> 别处的内容在本段怎么落地：状态流转与优先级都写进每条功能自己，不单独成文；用户故事取①段《使用场景》（`1e-使用场景.md`），本段按它推功能；grill / 压测在①段 1a（全场唯一一份 `grill-me`）；风险取①段《产品策略》的「假设与风险」。 +> +> （历史：本段收窄前的产出清单与其去向 → `_留痕/②段-已删除产出与方法论.md`） + +## ⭐⭐ ②—③ 交接口（唯一权威处 · 改边界只改这一块 · 2026-10-06 用户定案） + +> 🔴 「②段管什么、③段管什么」**只在本节定义一次**。本段其余章节、总入口 `product-planning/SKILL.md`、 +> `stage-discovery` 与 `stage-delivery` 的 `SKILL.md`、③段 `references/execution-runbook.md` 与 +> `references/layouts-tooling.md`，提到这条边界时一律**引用本节的行名**，⛔ 不许再复述清单。 +> 为什么立这一块：同型的复述病已经造成过真事故 —— 停线规则被三段写成「三种、②段写成「四种」， +> 两边长期漂着而没有任何门禁会报。单一可信源才拦得住。 +> 用户原话（本节的唯一出处，别处不再抄）：「3 是负责设计和交互，页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子」。 + +口径：②段钉骨架，③段做皮肉。 + +| 归②段（必须在本段定死） | 归③段（⛔ ②段不许写） | +|---|---| +| 有哪几页 | 配色 / 字体 / 间距 / 组件样式 / 动效 | +| 每页几个板块、板块怎么排 | 每个板块的视觉实现（怎么好看、怎么对齐、什么层次） | +| 跨页关系（怎么跳转） | 每个板块的交互行为（点哪、什么反馈、何时不可点） | +| 每页的主操作是什么 | 状态与空态的具体呈现 | +| 每条信息在哪一档承载（主屏常驻 / 可点入） | 响应式怎么变 | + +> ⭐ 骨架是判断基准，必须在②段定死。旧口径把「有哪几页」留在③段，结果就是③段做一版一个样，②段无从判断改得对不对。 +> ⛔ 交给③段时骨架是冻结的：③段不许新增 / 移动 / 删除板块，缺板块要回②段改。 +> 「归③段」那一列的六个词就是本段的**零视觉词红线**：本段其余章节与 `references/create-prd.md` 提到它时， +> 一律写成「见 §②—③ 交接口 的『归③段』列」，⛔ 不再逐处抄这六个词。 + +## 本段职责（2026-10-06 按「只细化功能」重划） + +本段回答一个问题：把①段的使用场景细化成哪些功能，这些功能长成一个什么骨架。拆成两问（原三问）： + +| 问 | 内容 | 落点 | +|---|---|---| +| 有哪些功能、优先级如何、什么不做 | 从每条使用场景推出功能条目；每条带优先级、状态流转、验收要点 | `2a-产品功能.md` | +| 这些功能长成什么骨架 | 有哪几页、每页几个板块、板块怎么排、跨页关系 | `2b-界面布局.md` | + +> ⭐ 本段产物的主体是功能条目的有无与优先级，这也是「产品功能」这个名字的依据。实测本项目 **24 条**功能定义（`F001`–`F024`）**落在④段产品文档**，②段 `prd/` 为空 —— 「功能落在哪段」按实际记，⛔ 不要拿本段的定位当既成事实写。 +> ⛔ 本段不许重开需求：需求澄清、grill 反问、取证都在①段做完了。本段假定需求已成立，只做功能取舍。 +> ⭐ 功能按使用场景组织（2026-10-06 用户定案），一条使用场景下可能放跨多个页面的功能。用户原话：「功能可以分使用场景梳理（可能是跨页面的）」。不按页面组织 —— 按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上。 + +## 2a 产品功能 + +| 子步 | 读 | 产出 | +|---|---|---| +| 2a 产品功能 | `references/create-prd.md` | `docs/pm/<项目>/prd/2a-产品功能.md` | + +回答：要做哪些功能、哪些明确不做、每条什么优先级、每个功能自身怎么流转。 + +⭐ **起手先复制模板**（2026-10-16 补）：`assets/产品规划模板.md` 的「一、功能清单」那张 12 列表 —— 表头与顺序照抄，把 `<尖括号>` 占位换成真实内容，⛔ 不要从空白页重写结构。 + +## 2b 界面布局 + +| 子步 | 读 | 产出 | +|---|---|---| +| 2b 界面布局 | `assets/diagram-design/SKILL.md`（第三方 skill 整树保留，其 `references/`、`scripts/`、`assets/` 路径均相对该目录解析） | `docs/pm/<项目>/prd/2b-界面布局.md` | + +回答：有哪几页、每页几个板块、板块怎么排、跨页关系怎么跳。 + +⭐ **起手先复制模板**（2026-10-16 补）：`assets/产品规划模板.md` 的「二、页面骨架」那张 8 列表 —— 表头与顺序照抄，把 `<尖括号>` 占位换成真实内容，⛔ 不要从空白页重写结构。 + +> 顺序是 2a → 2b：布局是功能清单的空间展开，功能还没定就画布局等于凭空发明版面。 +> ⛔ 2a 之前不再需要压测步骤，压测已前移①段 1a 的 B 节。 + +### 功能清单怎么组织（逐条可核） + +每个功能条目必须带齐这几样： + +| 字段 | 写什么 | 判据 | +|---|---|---| +| 功能名 | 一句话说清做什么（动词开头的用户语言） | ⛔ 不写实现名 | +| 来自哪条场景 | 追回①段《使用场景》（`docs/pm/<项目>/research/1e-使用场景.md`）的编号 | ⛔ 追不回的条目该砍 | +| 优先级 | P0 / P1 / P2 | 见下方「优先级」 | +| 状态流转 | 这个功能自身有哪几个状态、怎么迁移（不适用就写「无状态」） | ⛔ 不许省成空白 | +| 验收要点 | 怎么算做完（可观察） | ⛔ 不写「体验好」这类 | +| 跨哪些页面 | 这个功能在骨架的哪几页上发生 | 可为多页 | + +🔴 **输入缺失时怎么办（②段唯一分支，2026-10-16 补）**：「来自哪条场景」这一列的输入是①段《使用场景》；它缺失时（`1e-使用场景.md` 不存在，或①段收口时把它列进了豁免清单）⇒ **退化为追回 `1a` 决策表**： + +1. 到 `docs/pm/<项目>/research/1a-需求文档.md` 的决策表里逐条认领（A 节「问题与边界」／B 节「形态与状态」），把这一列改标成「来自 `1a-需求文档.md` §<节号>-<条目>」。 +2. 两条都追不到（`1e` 与 `1a` 都没有对应条目）⇒ 该功能条目**砍掉**，并写明「无需求来源，已砍」。 + +⛔ 不许因为上游缺文件就把这一列放空或写「未定」—— 那样「功能该不该有」就没有判据了。 +⛔ 也不许反过来：`1e` 与 `1a` 都在时，一律以 `1e` 为准，退化只在**缺失**时启用。 + +优先级（⛔ 不许凭空打分，见硬约束）： +- P0：不做则①段某条使用场景整条办不成 +- P1：不做则场景能办成但要多绕（本可用一次点击，变成三步） +- P2：不做不影响场景办成，只是更好用 + +> 优先级判据 = 一句可复述的话。本项目没有数据源，不填数字。 + +### 2b 界面布局怎么写 + +本份专管界面骨架，⛔ 不写功能条目的有无与优先级（那是 `2a-产品功能.md`）。一句话分工：`2a` 管「做哪些事」，`2b` 管「这些事落在哪几页、每页长什么结构」。 + +🔴 **骨架怎么来（2026-10-16 补）**：现读**目标产品整页快照**再挑板块 —— 路径与③段同源：`references/stage-delivery/assets/design-systems/<选定套>/assets/component-library/snapshot/<板块>.html`。②段从快照的板块集里**挑**（挑哪几块、怎么排），③段按挑好的骨架**做**；板块名一律照抄快照，⛔ 不许自造（第 1 轮返工的病根就是自造 `nav-item` × 21）。本项目真正用到的快照是 `snapshot/script.html`：选不到对应板块时，写明用的是哪一份快照、为什么。 + +| 问 | 回答 | 内容 | +|---|---|---| +| 页面关系 | 有哪几页、门开在哪、**新功能放在已有产品的哪一页** | 页面清单、页面流转、导航、**已有产品的页面 ＋ 新增块** | +| 页面内布局 | 房间里家具怎么摆 | 每页的板块清单 ＋ 排列顺序（wireframe 灰块粒度） | + +> ⭐ 拆成两份是 2026-10-07 的用户定案。旧写法一份装两半，同一件事要写两遍（比如 `header / side / footer` 既像页面框架又像页内板块）；拆开后各自只写自己那一侧，正好逼着把边界写明确。 +> 🔴 防重写规则（拆开后必须守）：页面级框架（`header / side / footer`）只在 `2b` 写一次；`2a` 的功能条目里只许出现「跨哪些页面」，⛔ 不许描述页面长什么样。 +> ⚠️ 粒度：本段给灰块框图（有哪些块、什么顺序），⛔ 不给视觉（颜色、字体、间距、圆角、层次）。视觉类六词（见 §②—③ 交接口 的『归③段』列），本段（含布局）仍不许写。 +> ⚠️ 旧 `ux/diagrams/system-architecture.html` 画的是系统组件之间的关系，属实现视角，已改名。本段要的是页面与板块，属产品视角，⛔ 不许再叫「系统架构」。 + +## 硬约束 +- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。 + +- ⭐ 本段不是压测入口（2026-10-06）：`grill-me` 全场只有①段一份，火力点已扩到覆盖「做成什么样、状态怎么流转」。⛔ 本段不许再开一轮反问 —— ①段 `1a-需求文档.md` 的决策表就是本段的压测输入。用户始终不回应时①段怎么处理，本段照旧继承，但不再自己去问。 +- ⭐ 假设照旧继承，但账在①段：`1a-需求文档.md` 带进来的每条 `【假设】`，在②段落盘时逐条给结论，只允许三种归宿 —— 已确认（写明确认人与时间）｜待实现且已排定确认时机（写明「在第几步落地前必须问」）｜`【已按假设落地】`（写清影响面 + 回退口径）。⛔ 第四种（既未确认、已进实现、又无落地说明）不许带进本段。 + - ⭐ 引用假设必须带状态：本段任何一条功能 / 状态流转 / 分档，只要依据是某条假设，就在括号里带上该假设的当前状态（`（依据 Q7 · 已确认）`、`（依据 Q10 · 【已按假设落地 · 影响面：每版全量复制 → 版本目录体积】）`）。下游③段据此判断这条能不能当硬约束用。 + - ⭐ 假设与实测要回头对账：凡靠假设得出的结论，一旦下游跑出实测结果，必须回填并改状态。实测踩坑：`PRD.md:132` 假设 3「单文件 HTML 在 `file://` 下能双击打开（③段需实测）」标着待实测，而③段早已实测了 16 版，事实成立却没人回填。 +- ⭐ 待确认 / 暂缓项必须带回收三字段（2026-10-02）：本段任何「待确认 / 暂缓 / 待定」条目必须同时写 复核人 ＋ 复核时机 ＋ 结论落点（哪个文件哪一节），三字段缺一不许落盘。⛔ 只写「暂缓」等于无限期搁置。 +- 「不做 / 移出」必须逐条核对，不许自行裁剪：写②段前、落盘后各做一次 —— 把②段里每一条「不做 / 移出 / 暂缓」与 `1a-需求文档.md` 的已拍板项逐条对照。凡涉及已拍板项，一律不得自行裁剪或改口径，必须列成「与已定决策的差异」表（原条目 / 原口径 / 拟改口径 / 理由）交用户显式确认。只写「已核对无冲突」不算核对，要给出对照过的条目数。 +- ⭐ 每条功能必须能追回①段《使用场景》（`1e-使用场景.md`）：追不回的功能就要么补一条场景、要么砍掉。这是本段唯一的功能有无判据，代替凭空打分。 +- ⭐ 状态流转写在功能条目里，⛔ 不再单独成文（2026-10-06）：每个功能条目自带「状态流转」字段。六项治理照旧全覆盖（失败恢复路径、持久化范围、并发冲突、幂等、超时迁移目标、不可逆操作二次确认），只是落点从独立文档移进功能条目。 + - ⭐ 状态放不到任何功能上的中间态，要么删掉，要么补一个功能条目让它服务。 +- ⭐ 骨架必须给全（2026-10-06）：②段的《界面布局》必须给全 §②—③ 交接口 的「归②段」列那几样，逐条对应。⛔ 缺任何一样，③段就没有方向。 + - 信息承载分档的判据：「删掉它，主操作还做得成吗」—— 答「做得成」就只能进「可点入」。⛔ 「能读到」= 可点入，不等于主屏常驻；不许以「②段要求能读到」为由把信息留在主屏。 +- ⛔ 本段（含布局）不许写视觉（六词清单见 §②—③ 交接口 的『归③段』列），一个字都不许出现。 +- ⭐ 文档前面必须配图（2026-10-15 用户令）：本段落盘的每份文档，正文（第一张表 / 第一小节）之前必须先给一张图 —— 本段画《页面与功能结构图》；用 `diagram-design` 画，⛔ 手写 Mermaid。图是正文内容，⛔ 不写成标题旁边或标题下面的注解小字。 +- 段内不反问，做完直接往下走。停线规则（哪几种情况停、怎么判）见 `product-planning` 的「执行规则」—— ⛔ 本段不复述，免得两处漂。 +- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。 + +## 完成标准 + +- `2a-产品功能.md` 与 `2b-界面布局.md` 两份都在，且只有这两份（⛔ 不许再产出 `grill-decisions` / `user-stories` / `priorities` / `pre-mortem` / `state-machine` / `diagrams` 六份中的任何一份；⛔ 也不许再退回单份 `PRD.md`） +- ②段的「不做 / 移出」清单逐条对照过①段已拍板项，差异行为 0 或每一行都已获用户显式确认（附对照条目数，不得只写「无冲突」） +- 功能清单每条带齐「功能名 / 来自哪条场景 / 优先级 / 状态流转 / 验收要点 / 跨哪些页面」六字段；⛔ 追不回①段场景的条目为 0 +- 状态流转六项治理全覆盖（失败恢复 / 持久化 / 并发 / 幂等 / 超时 / 不可逆二次确认），且落在功能条目内 +- 《界面布局》给全 §②—③ 交接口 的「归②段」列（含分档判据回答） +- ⛔ 全文零视觉词（六词清单见 §②—③ 交接口 的『归③段』列） +- 每条假设都有归宿（三选一，无第四种）；凡依据假设的功能 / 状态流转 / 分档，条目里都带上了假设状态标注 +- ⭐ 2a 与 2b 两份前面都配了图（用 `diagram-design`，⛔ 无手写 Mermaid） +- 本段所有「待确认 / 暂缓」条目都带齐 复核人 / 复核时机 / 结论落点 三字段 +- ⭐ 两份都过了「说人话」内容准则（源技能、判据与门槛见 `product-planning` 的「执行规则」内容准则条）；段末报告须写明「已过内容准则，评分 X/50」 + +### 六条可机核项（2026-10-16 补 · 逐条给读数，⛔ 不许只写「已核对」） + +| # | 判据 | 怎么核 | +|---|---|---| +| 1 | **页面清单条数 ＝ 原型 `.html` 文件数** | 数 `2b` 的「页面名」列行数，与 `designs/<项目>/*.html` 里**原型页**的个数比对（⛔ 产品文档、`3c-*`、`3d-*` 不算原型页） | +| 2 | **每个板块名 ∈ 目标产品整页快照的板块集** | 拿 `2b` 的「板块清单」列逐名去 `snapshot/<板块>.html` 里 grep；⛔ 自造名一律报红 | +| 3 | **功能条目数 ＝ ④段产品文档的 F 条数，且 F 编号唯一连续** | 数 `2a` 的 F 行数，与成品〈三、功能清单〉的 F 条数比对；再验 `F001…F00N` 无跳号无重号 | +| 4 | **每条 F 带齐**：场景编号（或退化后的 `1a` 条目）／优先级／状态流转／验收要点 | 逐行查四列非空；⛔「未定」「暂缓」不算已填 | +| 5 | **2a 的页面名／功能区在 2b 全追得到；2b 挂的 F 在 2a 全追得到** | 两个差集都要为空，读数写「正向 N 条全中／反向 M 条全中」 | +| 6 | **全文零视觉词**（清单见 §②—③ 交接口 的『归③段』列） | 逐词 grep 两份产物，命中数须为 0 | + +## 反面清单 + +- ⛔ 在本段重开一轮 grill 反问（2026-10-06）：反问已整套前移①段 1a，本段只细化功能 +- ⛔ 产出本段两份之外的文档（本段只 `2a` 与 `2b`，白名单由 `check_naming.py` 机器判） +- ⛔ 把「产品功能」与「界面布局」又塞回一份（2026-10-07 用户定案：这就是两个文档） +- ⛔ `2a` 里描述页面结构 / `2b` 里写功能条目的有无与优先级（越界即重写） +- ⛔ 按页面组织功能清单（2026-10-06）：功能要按使用场景组织，一条场景可跨多页；按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上 +- ⛔ 凭空给功能打分（Importance × Satisfaction / ICE / RICE）：没有数据源。优先级只能是 P0/P1/P2 + 一句可复述的判据 +- ⛔ 功能条目追不回①段《使用场景》（`1e-使用场景.md`）：追不回就要么补场景、要么砍条目 +- 用「移出第一版 / 不做」自行砍掉已拍板项，或只声称「已核对无冲突」却不列对照条目数 +- 在本段重开需求验证（该做取证与需求定义的是①段；本段假定需求已成立，只做功能取舍） +- ⛔ 骨架给不全（2026-10-06）：只给页面清单、不给每页板块与排列，或只给布局、不给跨页关系 —— ③段拿不到方向，就会一版一个样 +- ⛔ 把某条信息标为「主屏常驻」却答不上「缺了主操作就做不成事」：按判据应归「可点入」 +- 状态流转只画正常路径，不管失败与并发；或状态放不到任何功能条目上（凭空中间态） +- ⛔ 在本段写视觉（清单见 §②—③ 交接口）—— 那是③段 +- 越界去出原型或写说明文档（那是第③④段） +- 把 `【假设】` 原样带进②段当既定事实；或假设已被实现却从不回填状态 +- 只写「暂缓」而不给复核人 / 复核时机 / 结论落点 —— 等于让这条永远放着 +- ⛔ 两份没过「说人话」内容准则就落盘 —— 口径与门槛见 `product-planning` 的「执行规则」内容准则条 +- ⛔ 改本技能包的规则文件、却不过「说人话」这一关（2026-10-07）：规则和产出同一把尺子 —— 口径见 `product-planning` 的「执行规则」内容准则条 + +## 本段读什么、守什么 + +- 方法论两份：`references/create-prd.md`（功能清单）、`references/state-machine.md`（六项治理清单仍要读，落点变成功能条目内）。 +- 产物模板：`assets/产品规划模板.md`（两张表的表头与顺序的**唯一定义处**；2a／2b 起手都从它复制）。 +- 绘图资产：`assets/diagram-design/`（整树保留，供画布局图）。 +- 贯穿纪律：同一件事只写一遍 —— 同一批人 / 同一批场景若在①②两段各写一份，必然打架。 + +📎 本段收窄前的产出清单与其去向（含方法论去留）见 `_留痕/②段-已删除产出与方法论.md` —— 正文不展开；防复活由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` / `WHITELIST` 机器判。 diff --git a/product-planning/references/_留痕/N7-返工-20261016/scripts/check_naming.py b/product-planning/references/_留痕/N7-返工-20261016/scripts/check_naming.py new file mode 100644 index 0000000..2ec5f85 --- /dev/null +++ b/product-planning/references/_留痕/N7-返工-20261016/scripts/check_naming.py @@ -0,0 +1,448 @@ +#!/usr/bin/env python3 +# -*- coding: utf-8 -*- +"""四段流水线**命名一致性**自检（纯静态文本比对，不需要渲染、不需要外部依赖）。 + +只查一件事：**四段的段名 / 子步名，在总入口、各段 SKILL.md、各段 references 之间有没有漂。** +⛔ 本脚本**不查视觉、几何、配色** —— 那些判据归③段 §供给·工艺数值判据，本脚本一概不碰。 + +为什么需要它（不是"为了严谨"，是实测过的两次真实事故）： + - 2026-10-02：段名从「需求调研/功能规划/界面与交付」改成「产品需求/产品功能/界面交互」， + `SKILL.md` 改了，但 `references/grill-me.md` 的 H1 仍写「需求澄清（grill-me · 调研段）」。 + - 同日：`stage-requirements/SKILL.md` 的子步表写「2b 功能流转」，正文 H2 却是「## 2b 状态机」； + `product-planning` 的④段子步列只写「4a 说明区/ 演示引导」，漏了 4b / 4c。 + 这三处**没有任何门禁会报错** —— 只能靠回读，而回读会漏。 + +用法： + python scripts/check_naming.py --ws <工作区> # 查技能包自身 + 该工作区的产出白名单 + python scripts/check_naming.py --root <某个技能根> # 只查一份 +退出码：0 = 全过；1 = 有 FAIL。 +""" + +import argparse +import os +import pathlib +import re +import sys + +# ── 权威口径表。改段名/子步名时，先改这里，再改文档 ────────────────────────── +STAGES = [ + { + "slug": "stage-discovery", + "cn": "产品需求", + "h1": "# ① 产品需求", + # 2026-10-06 用户定案：①段收为五子步五产出，编号 1a~1e，全部落 research/ + # 旧「1a 需求定义 / 1b 需求取证 / 1c 产品定位与场景」三子步废止（见 DEPRECATED） + "subs": ["1a 需求文档", "1b 竞品分析", "1c 用户画像", "1d 产品策略", "1e 使用场景"], + }, + { + "slug": "stage-requirements", + "cn": "产品功能", + "h1": "# ② 产品功能", + # 2026-10-06 用户定案：②段收窄为「只细化功能」，2b/2c 删除，三子步并为一个 + # 2026-10-07 用户定案：②段一拆二 —— 产品功能 / 界面布局 两个子步两文档 + "subs": ["2a 产品功能", "2b 界面布局"], + }, + { + "slug": "stage-delivery", + "cn": "界面交互", + "h1": "# ③ 界面交互", + "subs": ["3a 视觉规范", "3b 原型", "3c GPT参考版", "3d 审查打磨"], + }, + { + "slug": "stage-proto-doc", + "cn": "原型说明文档", + "h1": "# ④ 原型说明文档", + # 4b/4c 允许只在一处出现完整（总入口与段内都写全），但**两处都必须能读到** + "subs": ["4a 场景盘点", "4b 说明区", "4c 演示引导"], + }, +] + +# ④段沿革（2026-10-14 → 10-15）：10-14 按用户令删掉旧版（做法＝往原型 HTML 注入说明区注解层，实测不好用）； +# 10-15 用备份里的新版装上（两份产物 ＋ R/S/F 编号 ＋ 四块框架），本表随之恢复该项。 + +# 已废止的旧名。出现在「废止理由块」里是正当的（那是留痕）， +# 所以这里只做**提示级**检查（不计入 FAIL），人工确认上下文即可。 +DEPRECATED = [ + "需求调研", "功能规划", "需求与结构", "界面与交付", + "1a 需求澄清", "2a 需求压测", "2b 状态机", "2c 图示", "1b 调研", "1c 方案", + # 2026-10-06 ②段收窄：以下三个子步名与旧产出名一并废止 + "2a 功能定义与压测", "2b 功能流转", "2c 功能图示", + "1c 产品定位与商业设计", + # 2026-10-06 ①段收为五子步：旧三子步名废止（产出改落 research/1a~1e） + "1a 需求定义", "1b 需求取证", "1c 产品定位与场景", + # 2026-10-06 ①段旧产出名废止：00/01 合并为 1a，其余按组号改子步号 + "00-问题定义.md", "01-需求澄清.md", + "10-参考实装拆解.md", "11-竞品分析.md", "12-用户画像.md", + "strategy/30-产品策略.md", "strategy/31-使用场景.md", + # 2026-10-14 旧版④段的做法废止（状态轴 / 三段必填 / 逐步骤演示），段名与子步名**仍在使用**， + # 故不列入本表；新版的判据在段内 `references/doc-language-spec.md` 等三份。 +] + +# ⛔ 2026-10-06 用户定案：①段**产出白名单**——本段只许这五份，第 6 份须用户明确要求。 +# 判据：扫 `docs/pm/<项目>/research/` 的实际文件名，出现白名单外的 `.md` 即 FAIL。 +# ⛔ 用 os.walk 时**必须逐层拆开**：`research/` 与 `prd/` 是两个不同的白名单。 +WHITELIST = { + "stage-discovery": { + "dir": "research", + "allow": ["1a-需求文档.md", "1b-竞品分析.md", "1c-用户画像.md", + "1d-产品策略.md", "1e-使用场景.md"], + }, + # 🔴 2026-10-07 用户定案：「2 产品功能 和 界面布局不就是两个文档嘛」 + # ⇒ ②段同样是白名单制：`prd/` 里**只许这两份**（⛔ 不许退回单份 `PRD.md`）。 + "stage-requirements": { + "dir": "prd", + "allow": ["2a-产品功能.md", "2b-界面布局.md"], + }, +} + +# 已从磁盘移除的资产。文档里提到它们时，只允许出现在**说明性文字**里 +# （"原主干 X 已不存在"这类），一旦出现在「必读表/调用指令」位置就是悬空引用。 +REMOVED_ASSETS = ["ui-page-design"] + +# ⛔ 已废止的目录形态。它们若出现在正文的「产出 / 只读 / 必读」位置 ⇒ 真残留（FAIL）。 +# 2026-10-08 实测：`usage-scenario.md` 的产出行、`stage-proto-doc/SKILL.md` 的输入表、 +# 总入口的「只读」清单，三处还指着已废的 `strategy/` 与 `ux/`，而当时没有任何门禁会报。 +# 豁免：行内出现下面任一废止标记时视为正当留痕（说明"原来叫什么、现在改成什么"）。 +DEAD_PATHS = { + r"strategy/30-|strategy/31-|docs/pm/[^`\s]*/strategy/": + "已废的 ①段 strategy/ 目录（现全部落 research/1a~1e）", + r"ux/state-machine|ux/diagrams|docs/pm/[^`\s]*/ux/": + "已废的 ②段 ux/ 目录（状态流转已移进 prd/2a 的功能条目）", +} +DEAD_PATH_EXEMPT = ("旧", "已废", "已改名", "曾", "历史上", "移进", "移到", "改为", + "废止", "原 ", "原标题", "历史：") + +# ⛔ 单一可信源登记表（2026-10-08 立）。每条 = 一个「会变的事实」的唯一定义处。 +# 判据：除定义处外，其余任何 md（不含 `归档/`、`_留痕/`、`assets/`、`_superseded*`） +# 里出现该模式 ⇒ FAIL。`authority: None` 表示全包禁写（该措辞本身就不该再出现）。 +# 为什么需要它：复述才是漂移的根因 —— 实测一个设定被复述约 40 处， +# 改一次动三份文件 17 处仍漏 13 处口径（2026-10-08 用户：「是不是 本身就是问题」）。 +# ⚠️ 加新条目前先确认「这个事实真的会变」；不会变的（如历史沿革、用户原话留痕）别往里塞。 +AUTHORITY = [ + {"fact": "②③边界（②段管什么 / ③段管什么）", + "authority": "references/stage-requirements/SKILL.md", + "pattern": r"归②段（[^）]*）\s*\|\s*归(?:③段|本段)（", + "why": "两侧对照表只许在②段 SKILL.md 的 §②—③ 交接口 定义一次"}, + {"fact": "停线规则（哪几种情况停）", + "authority": "SKILL.md", + "pattern": r"只有[三四]种情况停", + "why": "⛔ 全包禁写 —— 口径只在本包 SKILL.md 的「执行规则」，各段一律引用"}, + {"fact": "可选档骨架名单（营销页向那 8 个）", + "authority": "references/stage-delivery/references/layouts-tooling.md", + "pattern": r"hero\s*/\s*features|hero/features", + "why": "骨架名单与「为什么工具型不能套」只许在 layouts-tooling.md 开头写一次"}, + {"fact": "说人话门槛数值", + "authority": "SKILL.md", + "pattern": r"45\s*/\s*50", + "why": "门槛只许在本包 SKILL.md 的「执行规则」内容准则条 定义一次"}, + {"fact": "对比度门槛数值", + "authority": "references/stage-delivery/references/execution-runbook.md", + "pattern": r"4\.5:1", + "why": "数值只许登记在 runbook 的数值判据段"}, + {"fact": "设计契约字段的展开清单", + "authority": "references/stage-delivery/references/execution-runbook.md", + "pattern": r"重复项的信息量（", + "why": "十二字段的逐条展开只许在 runbook §2.1"}, + {"fact": "②—③ 定案用户原话", + "authority": "references/stage-requirements/SKILL.md", + "pattern": r"一会一个样子", + "why": "用户原话只许在②段 §②—③ 交接口 出现一次（可追溯性由那一处承担）"}, + {"fact": "1b 两体例的定案用户原话", + "authority": "references/stage-discovery/references/competitor-analysis.md", + "pattern": r"有独立分析也有汇总分析", + "why": "只许在 1b 方法论里写一次，其余引 §0.4"}, + {"fact": "grill-me 的 A / B 节火力点", + "authority": "references/stage-discovery/references/grill-me.md", + "pattern": r"做成什么样、哪些情况不成立、状态怎么流转", + "why": "火力点定义只许在 grill-me.md"}, + {"fact": "选定套的组件文件名（默认档与可选档不同名）", + "authority": "references/stage-delivery/references/execution-runbook.md", + "pattern": r"\+\s*`?components\.html`?", + "why": "⛔ 照可选档（153 套）的命名去找默认档的文件会扑空 —— 默认档那套没有 components.html。" + "2026-10-08 实测：D1 步骤照这个名字找 ⇒ 版式结构与组件族整层漏掉 ⇒ 「用了它的样式、没有它的排版」。" + "只许在 runbook §2.2「D1 读什么」里作为反面留痕出现"}, +] + +# ⛔ 2026-10-02 用户定案**永久删除**的产出与方法论（防被加回来） +# 判据：命中位置若落在「已删除的产出」留痕块 / 废止说明里 → 正常，只报 HINT。 +DEAD_OUTPUTS = { + "opportunity-solution-tree": "机会树（用户：完全没用，都是编的）", + "20-机会树.md": "机会树产物（用户：完全没用，都是编的）", + "value-proposition": "价值主张方法论（用户：不如改为使用场景）", + "strategy/31-价值主张.md": "价值主张产物（已改名为 31-使用场景.md）", +} + +results = [] # (level, check, detail) + + +def add(level, check, detail): + results.append((level, check, detail)) + + +def read(path): + if not os.path.isfile(path): + return None + with open(path, encoding="utf-8", errors="ignore") as f: + return f.read() + + +def frontmatter_ok(text): + """frontmatter 是否闭合。判法：第 1 行是 ---，且其后 12 行内能找到闭合 ---。 + + ⛔ 别用 text.split('---')[0] 取 frontmatter —— 那是**开标记之前**的片段， + 逻辑写反，会把每个文件都误报成「无 frontmatter」。 + """ + lines = text.split("\n") + if not lines or lines[0].strip() != "---": + return False + return any(l.strip() == "---" for l in lines[1:12]) + + +def check_root(root, label): + root = os.path.abspath(root) + if not os.path.isdir(root): + add("FAIL", f"[{label}] 技能根存在", root) + return + add("PASS", f"[{label}] 技能根存在", root) + + # 1) 每段：frontmatter 闭合 + H1 与权威表一致 + 每个子步都有 H2 + # ⚠️ 2026-10-05 整合后：四段收进 references//，不再是技能根下的平级目录。 + # 本函数按「技能包 = 一个目录，SKILL.md 在最外层」的形态定位： + # /SKILL.md ← 总入口（曾为 /product-planning/SKILL.md） + # /references//SKILL.md ← 四段（曾为 //SKILL.md） + # ⛔ 不许改回平级探测：那会让整合形态静默退回「一目录套多技能」而门禁照样全绿。 + for st in STAGES: + p = os.path.join(root, "references", st["slug"], "SKILL.md") + text = read(p) + if text is None: + add("FAIL", f"[{label}] references/{st['slug']}/SKILL.md 存在", p) + continue + rel = f"references/{st['slug']}/SKILL.md" + + add("PASS" if frontmatter_ok(text) else "FAIL", + f"[{label}] {rel} frontmatter 闭合", "") + + h1s = [l.rstrip() for l in text.split("\n") if l.startswith("# ") and "产品" in l or l.startswith("# ") and "界面" in l or l.startswith("# ") and "原型说明" in l] + if st["h1"] in text: + add("PASS", f"[{label}] {rel} H1 = `{st['h1']}`", "") + else: + add("FAIL", f"[{label}] {rel} H1 应为 `{st['h1']}`", + "实际 H1 行: " + " | ".join(l.strip() for l in text.split("\n") if l.startswith("# ")[:2])) + + for sub in st["subs"]: + key = sub.split()[0] # "1a" / "3b" ... + has_h2 = any(l.startswith(f"## {key} ") for l in text.split("\n")) + add("PASS" if has_h2 else "FAIL", + f"[{label}] {rel} 有 H2 章节 `{sub}`", + "" if has_h2 else f"找不到 `## {key} ` 开头的章节 —— 子步表与正文不一致") + + # 2) 总入口：段名四件套 + 子步列表完整 + 交接口表 + # ⚠️ 2026-10-05 整合后总入口就是技能包自己的 SKILL.md（不再有 product-planning/ 子目录） + pp = os.path.join(root, "SKILL.md") + text = read(pp) + if text is None: + add("FAIL", f"[{label}] SKILL.md 存在", pp) + return + rel = "SKILL.md" + + for st in STAGES: + num = STAGES.index(st) + 1 + circled = "①②③④"[num - 1] + # 段名必须以「圈号 + 空格 + 段名」成对出现，避免只匹配到散落正文 + ok = f"**{circled} {st['cn']}**" in text + add("PASS" if ok else "FAIL", + f"[{label}] {rel} 四段结构表含 `{circled} {st['cn']}`", "") + + # 子步：总入口表里每个子步都要能被逐个读到 + for st in STAGES: + for sub in st["subs"]: + if sub.split()[0] in ("3d", "4b", "4c"): + # 3d/4b/4c 在总入口可能与相邻子步合并书写，只要求"子步号 + 关键词"能被搜到 + kw = sub.split(" ", 1)[1] if " " in sub else sub + ok = (sub in text) or (kw in text) + else: + ok = sub in text + add("PASS" if ok else "FAIL", + f"[{label}] {rel} 四段结构表子步列含 `{sub}`", "") + + # 交接口表：三条边必须都在 + for edge in ("① → ②", "② → ③", "③ → ④"): + add("PASS" if edge in text else "FAIL", + f"[{label}] {rel} 交接口表含 `{edge}`", "") + + # 3) 悬空引用：已移除资产**不许出现在必读表的数据行里** + # ⛔ 只扫表格数据行（以 `|` 开头且含路径形态），不扫章节前的告示段 —— + # 告示里写"原必读表指向 X，该目录已不在磁盘上"是**正当留痕**，不是悬空引用。 + # 判据形态：形如 `| **D0** | ...ui-page-design... | ... |` 才算。 + runbook = read(os.path.join(root, "references", "stage-delivery", "references", "execution-runbook.md")) + if runbook: + m = re.search(r"## 1\. 必须加载的文件(.*?)(?=\n## )", runbook, re.S) + section = m.group(1) if m else "" + table_rows = [l for l in section.split("\n") + if l.strip().startswith("|") and "---" not in l] + for asset in REMOVED_ASSETS: + bad = [l.strip()[:90] for l in table_rows + if asset in l and "取代原" not in l] + add("FAIL" if bad else "PASS", + f"[{label}] runbook 必读表数据行未引用已移除资产 `{asset}`", + "；".join(bad) if bad else "") + + # 5) 单一可信源：会变的事实只许在定义处出现，别处出现即复述（复述必然漂） + for spec in AUTHORITY: + auth = (os.path.normpath(os.path.join(root, spec["authority"])) + if spec["authority"] else None) + bad = [] + for dp, dn, fn in os.walk(root): + dn[:] = [d for d in dn + if d not in ("__pycache__", "_留痕", "归档", "assets")] + for f in fn: + if not f.endswith(".md") or f.startswith("_superseded"): + continue + p = os.path.join(dp, f) + if auth and os.path.normpath(p) == auth: + continue + tt = read(p) + if not tt: + continue + for i, l in enumerate(tt.split("\n"), 1): + if re.search(spec["pattern"], l) and not any( + w in l for w in ("已于", "历史", "废止", "留痕")): + bad.append(f"{os.path.relpath(p, root).replace(chr(92), '/')}#{i}") + add("FAIL" if bad else "PASS", + f"[{label}] 单一可信源：{spec['fact']}", + (f"⛔ 复述出现在 {'；'.join(bad[:6])} —— {spec['why']}" if bad else "")) + + # 4) 提示级：旧名 / 已删项出现在哪（供人工判上下文，不计入 FAIL） + # ⚠️ 2026-10-08 修 bug：原实现先跑了一个空循环（只把文件名读进 `t`、什么都不做）， + # 紧接着的 DEPRECATED 判断又误用了那个上一轮残留的 `t`（该用本轮读到的 `tt`） + # ⇒ 旧名提示恒不触发，`strategy/30-产品策略.md` 这类真残留被静默放过（假绿）。 + # 现合并成一个循环，一律用本轮读到的 `tt`。 + for dp, dn, fn in os.walk(root): + dn[:] = [d for d in dn if d != "__pycache__"] + for f in fn: + if not f.endswith(".md"): + continue + p = os.path.join(dp, f) + tt = read(p) + if not tt: + continue + for key, why in DEAD_OUTPUTS.items(): + if key in tt: + lines = [i for i, l in enumerate(tt.split(chr(10)), 1) if key in l] + add("HINT", f"[{label}] {os.path.relpath(p, root)} 出现已删除项 `{key}`", + f"{why}｜行 {lines[:5]} —— 确认是否落在废止说明/留痕里（正当）") + + for old in DEPRECATED: + if old in tt: + lines = [i for i, l in enumerate(tt.split("\n"), 1) if old in l] + add("HINT", f"[{label}] {os.path.relpath(p, root)} 出现旧名 `{old}`", + f"行 {lines[:6]} —— 确认是否落在「废止理由块」内（正当）还是真残留") + + # 4c) 旧产物路径残留：已废目录形态出现在正文里就是真残留（告示/留痕里的除外） + # ⛔ 不要指望 DEPRECATED 的 HINT —— 它只提示不拦；路径错会让下游整段读空文件。 + for dp, dn, fn in os.walk(root): + dn[:] = [d for d in dn if d not in ("__pycache__", "_留痕")] + for f in fn: + if not f.endswith(".md"): + continue + p = os.path.join(dp, f) + tt = read(p) + if not tt: + continue + for pat, why in DEAD_PATHS.items(): + hits = [(i, l.strip()[:80]) for i, l in enumerate(tt.split("\n"), 1) + if re.search(pat, l) and not any(w in l for w in DEAD_PATH_EXEMPT)] + add("FAIL" if hits else "PASS", + f"[{label}] {os.path.relpath(p, root)} 无悬空旧路径 `{why}`", + "；".join(f"行{i}: {l}" for i, l in hits[:4]) if hits else "") + + +def check_whitelist(ws, label): + """①②段产出白名单：`docs/pm/<项目>//` 里出现白名单外的 .md ⇒ FAIL。 + + ⛔ 这是**产出层**门禁，与命名门禁不同源：命名管"文档里写的名字有没有漂"， + 本函数管"磁盘上到底多出了什么文件"。2026-10-06 事故：某轮自作主张多产了一份 + 《参考实装拆解》，用户反复看到"冒出来的不相关的文档" ⇒ 从此用机器判。 + ✅ 2026-10-07 扩到②段（`prd/` 只许 `2a-产品功能.md` / `2b-界面布局.md`）—— + 两段同为白名单制，⛔ 不出现"①段严、②段松"这种各说各话。 + """ + import glob + for slug, rule in WHITELIST.items(): + pat = os.path.join(ws, "docs", "pm", "*", rule["dir"]) + for d in glob.glob(pat): + if not os.path.isdir(d): + continue + proj = os.path.basename(os.path.dirname(d)) + extra = sorted(f for f in os.listdir(d) + if f.endswith(".md") and f not in rule["allow"]) + rel = os.path.relpath(d, ws).replace("\\", "/") + seg = "①段" if slug == "stage-discovery" else "②段" + add("FAIL" if extra else "PASS", + f"[{label}] {seg}产出白名单 `{rel}`", + f"白名单外文件：{extra} —— ⛔ 该段只许 {len(rule['allow'])} 份（{rule['allow']}），" + f"多出的须用户明确要求" if extra else "无白名单外文件") + + +def main(): + ap = argparse.ArgumentParser() + ap.add_argument("--root", action="append", default=None, + help="技能根目录，可重复；默认只查本技能包自身") + ap.add_argument("--ws", default=None, + help="工作区根（含 docs/pm 的那一层）；默认从 cwd 向上找") + args = ap.parse_args() + + # 本文件位于 <技能包>/scripts/ ⇒ 上溯 2 层 = 技能包（SKILL.md 就在这层） + skill_root = os.path.dirname(os.path.dirname(os.path.abspath(__file__))) + # 🔴🔴 2026-10-07 技能迁全局后的**必须修正**： + # 旧写法 `ws = os.path.dirname(skill_root)` 是按「技能包在工作区根」写的。 + # 技能从工作区搬到技能根（`<技能根>/product-planning/`）之后， + # `ws` 会算成技能根 ⇒ **`docs/pm/*` 一个都扫不到** + # ⇒ `check_whitelist()` 静默扫零个目录、**恒绿通过**（假绿比报红更危险）。 + # ⇒ 工作区一律**显式给**：`--ws <工作区>`；没给就向上找「含 docs/pm 的那一层」， + # 再找不到就**明确报 FAIL**，⛔ 绝不静默跳过。 + roots = args.root or [skill_root] + ws = args.ws + if not ws: + _p = pathlib.Path.cwd() + for _ in range(6): + if (_p / "docs" / "pm").is_dir(): + ws = str(_p) + break + _p = _p.parent + if not ws or not os.path.isdir(os.path.join(ws, "docs", "pm")): + add("FAIL", "找得到工作区（`docs/pm` 那一层）", + "⛔ 未找到 ⇒ 产出白名单**没被真正检查**。请显式传 `--ws <工作区>`。") + ws = ws or os.getcwd() + + for r in roots: + check_root(r, os.path.basename(os.path.dirname(r.rstrip("/")) if r.endswith("skills") else r)) + + # 产出白名单只查一次（它是**磁盘状态**，与技能根有几份无关） + check_whitelist(ws, "产出白名单") + + fails = [x for x in results if x[0] == "FAIL"] + hints = [x for x in results if x[0] == "HINT"] + passes = [x for x in results if x[0] == "PASS"] + + for lvl, check, detail in results: + if lvl == "HINT": + print(f"[提示] {check}" + (f" —— {detail}" if detail else "")) + print() + for lvl, check, detail in fails: + print(f"[FAIL] {check}" + (f" —— {detail}" if detail else "")) + for lvl, check, detail in passes: + print(f"[过] {check}") + + print() + print(f"小计：通过 {len(passes)} ｜ 失败 {len(fails)} ｜ 提示 {len(hints)}") + if fails: + print("⛔ 有 FAIL —— 上面的不一致必须修完再跑流水线。") + return 1 + print("✅ 命名一致性全过。") + if hints: + print("ℹ️ 提示项需人工看一眼上下文（旧名出现在废止理由块里是正当留痕）。") + return 0 + + +if __name__ == "__main__": + sys.exit(main()) diff --git a/product-planning/references/_留痕/SKILL-总入口-20261016加element-picker前.md b/product-planning/references/_留痕/SKILL-总入口-20261016加element-picker前.md new file mode 100644 index 0000000..4613249 --- /dev/null +++ b/product-planning/references/_留痕/SKILL-总入口-20261016加element-picker前.md @@ -0,0 +1,314 @@ +--- +name: product-planning +description: 产品规划总入口（唯一入口），四段式调度：① 产品需求 ② 产品功能 ③ 界面交互 ④ 原型说明文档。四段以 references/stage-* 承载，本文件是总调度与约束。可整段跑也可只调一段。当用户要做产品规划、从零做新产品、只做某一阶段、或不知道从哪开始时调用。 +--- + +# 产品规划总入口 + +> 本 skill 由模型按需自动加载，没有斜杠命令。对话里还没定出对象时，先按「项目与路径约定」定出 `<项目>`；定不出来就停下问用户，不要自行假设。 + +## 用途 + +用户丢来一句模糊想法（例如「我要做一个 AI 短剧分镜画布」）时，本 skill 判断该走哪一段，只做那一段的最小必要工作，产出可交付物，再推进到下一段。 + +本文件管调度与约束。各段怎么做，写在 `references/stage-*` 各自的文件里。 + +## 四段结构（可整段跑，也可只调一段） + +| 段 | 回答的问题 | 子步 | 调用 | 产出物 | +|---|---|---|---|---| +| **① 产品需求** | 要做的东西凭什么成立：什么问题、为谁、为什么值得做 | 1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景 | `stage-discovery` | `docs/pm/<项目>/research/*`。其中 1b 交两种体例：`research/1b-竞品分析.md`（汇总对比）＋ `research/1b-独立分析/<竞品名>.md`（独立分析） | +| **② 产品功能** | 要做哪些功能、什么不做、长成什么骨架 | 2a 产品功能 / 2b 界面布局 | `stage-requirements` | `docs/pm/<项目>/prd/2a-产品功能.md` 与 `docs/pm/<项目>/prd/2b-界面布局.md`（两份） | +| **③ 界面交互** | 长什么样、怎么操作 | 3a 视觉规范 / 3b 原型 / 3c GPT参考版 / 3d 审查打磨 | `stage-delivery` | `designs/<项目>/DESIGN.md`、`designs/<项目>/*.html`、`designs/<项目>/3c-GPT参考版.md` | +| **④ 原型说明文档** | 现有原型怎么用、每条功能落在哪个页面、坏了怎样、怎么核对（文档按七节铺：原型地址 → 页面结构 → 功能清单 → 使用场景 → 操作流程 → 页面导航 → 原型状态取值） | 4a 场景盘点 / 4b 说明区 / 4c 演示引导（可选） | `stage-proto-doc` | 原型内嵌说明区 ＋ 独立产品文档 `designs/<项目>/<产品项目名>.html`（两份共用同一套 P 页面／S 场景／F 功能／J 二级功能编号） | + +四段只通过落盘文件耦合。段间交接口如下，这是唯一的契约，越界即失效： + +| 交接 | 由谁给 | 给什么 | 给到哪为止 | +|---|---|---|---| +| ① → ② | ① | 问题定义、需求澄清决策表（含 grill 压测的 B 节：做成什么样 / 哪些情况不成立 / 状态怎么流转）、取证结论（1b 汇总对比体 ＋ 1b 独立分析体、1c 用户画像）、产品定位、《使用场景》＝用户故事（②段功能的直接推导依据） | 功能清单归②段产出，1a 写到需求与形态为止 | +| ② → ③ | ② | 功能清单（每条带优先级 ＋ 状态流转）、界面布局（有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系）、每页主操作、信息承载分档（主屏常驻 / 可点入） | 视觉归③段。骨架必须给全，骨架不给全，③段就一版一个样 | +| ③ → ④ | ③ | 已跑通的单文件原型 HTML（页面、模块、控件、状态、交互、跳转、反馈＝界面事实的唯一依据） | 说明区与独立产品文档归④段；⛔ ④段不重新规划产品、不重新设计界面 | + +> 口径：②段钉骨架，③段做皮肉。两侧逐行对照与用户原话只在②段 `references/stage-requirements/SKILL.md` 的 §②—③ 交接口 定义一次 —— 本入口不复述。要点两条：②段要给全「归②段」列；③段不许增删移动板块，缺板块回②段改。 + +> ②→③ 最容易搞坏。旧病灶：②段说「必须能读到」，③段读成「必须常驻主屏」，五类信息就全铺一屏成了信息墙。分档表把「读到」明确成「一次点击内可达」，防的就是这句歧义。骨架是灰块（有哪些块、什么顺序），③段给的是视觉与交互实现（排版、点哪有什么反馈、空态、响应式）。两件事各管一维，③段不会退化成照抄。 + +> 四段各占一个词，互不共用（2026-10-02 定）：产品 / 功能 / 界面 / 说明。改段名前先对照这张表；两个段名里出现同一个词，边界一定在漂。旧名「调研与方案 / 需求与结构」都含「需求」，③段旧名里的「交付」是三段共有的属性，都属名实不符，已改。 +> 🔴 **④段的沿革（2026-10-14 → 10-15）**：10-14 按用户令删掉**旧版**④段 —— 旧做法是往原型 HTML 注入说明区注解层（状态 → 场景 → 从左到右流程图 → 功能作用/输入边界/异常情况 三段 → 逐步骤演示引导），实测没法用，整段连方法论一并撤掉。10-15 用备份里的**新版**④段装上：改成「解释与记录现有原型」，交**两份产物**（原型内嵌说明区 ＋ 独立产品文档 `designs/<项目>/<产品项目名>.html`），内容先按四块＋附录铺，随后整套同步成**七节**（原型地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值），编号改用 P 页面／S 场景／F 功能／J 二级功能，并带一份现成模板 `references/stage-proto-doc/assets/产品文档模板.html`。判据正文在 `references/stage-proto-doc/`，⛔ 旧版那套（状态轴、三段必填、逐步骤演示）不再使用。 +> ①叫「产品需求」不叫「需求调研」：该段产出 `research/1a-需求文档.md`、`1b-竞品分析.md`、`1c-用户画像.md`，也产出 `1d-产品策略.md`、`1e-使用场景.md`，「调研」二字盖不住后半截。 +> ⭐ 1b 是①段唯一交两种体例的子步：独立分析体 `research/1b-独立分析/<竞品名>.md`（竞品池每一个一份），汇总对比体 `research/1b-竞品分析.md`（恒一份）。职责边界与定案原话见 `references/stage-discovery/references/competitor-analysis.md` §0.4。 + +⭐ `grill-me` 全场只有①段一份（2026-10-06 用户定案）：①段那份按 A / B 两节提问，火力点划分、节次归属与定案原话见 `references/stage-discovery/references/grill-me.md` —— ⛔ 本入口不复述。B 节结论落进 `research/1a-需求文档.md`。 + +⭐ ②段产出两份（2026-10-06 收窄，2026-10-07 定为两份）：`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 ＋ 状态流转）与 `docs/pm/<项目>/prd/2b-界面布局.md`（页面关系 ＋ 页面内板块布局）。定案原话与理由见 `references/stage-requirements/SKILL.md` 开头。 + +（交接口反转前的口径、②段收窄前的产出清单与去向 → `references/_留痕/③段与总入口-旧口径.md`） + +⚠️ ①段功能按「使用场景」组织（一条场景可跨多个页面），不按页面组织。 + +段内的子步顺序、方法论文档、硬约束、完成标准，都在各段自己的 `SKILL.md` 与 `references/` 里。 + +①段 1a 需求文档：全程最先做，且只做一次。用 grill-me 与用户互动，产出 `docs/pm/<项目>/research/1a-需求文档.md`（开头写清做什么 / 为谁 / 不做什么，往下是决策表）。 + +## 项目与路径约定（单一真源） + +> 四段全部遵守本节。各段 `SKILL.md` 与 `references/` 里出现 `docs/pm/...` 时，`<项目>` 一律指本节定义的 slug。 + +### `<项目>` 是什么 + +项目 slug 用小写字母、数字、连字符（例 `my-tool`、`video-canvas`）。它就是项目目录这一层的目录名，一个字都不能差，**两个根下同名**。产物**分两个根**落： + +| 根 | 路径 | 装什么 | +|---|---|---| +| 🔴 **文档根** | `docs/pm/<项目>/` | ①段 `research/`（`1a`~`1e`）、②段 `prd/`（`2a-产品功能.md` ／ `2b-界面布局.md`）、跨段 `专题/` | +| 🔴 **设计根** | `designs/<项目>/` | ③段 `DESIGN.md` ＋ 原型 `*.html` ＋ `3c-GPT参考版.md` ＋ 3d 审查留痕件 ＋ 截图 `_gate_shots/`；④段 `<产品项目名>.html` | + +⚠️ **②段 prd 归文档根**，⛔ 不跟③段一起搬 —— 它与①段 `research/` 同根，③段的机检脚本也按 `docs/pm/*/prd/2b-*.md` 去定位它（`find_doc`）。⛔ 已废的那层 `ui/` 子目录不要再写进任何判据。 + +### slug 怎么定（按序取第一个成立的） + +| 序 | 条件 | 取值 | +|---|---|---| +| 1 | 用户在当前会话里明确说了项目名 | 该名字 slug 化 | +| 2 | `.registry/current-project` 存在且非空 | 其内容 | +| 3 | `docs/pm/` 下恰有一个非 `_` 开头的目录 | 该目录名 | +| 4 | 以上都不成立 | 停下问用户 | + +写任何文件之前先核对：目标路径里的 `<项目>` 段与按上表得出的 slug 是否一致。不一致就停下说明，不要「先写了再说」——猜错会把产物写进别的项目，事后极难拆干净。 + +### 产物落哪 + +| 段 | 路径 | +|---|---| +| ① 产品需求 | `docs/pm/<项目>/research/` | +| ② | `docs/pm/<项目>/prd/` | +| ③ | `designs/<项目>/DESIGN.md`、`designs/<项目>/*.html`、`designs/<项目>/3c-GPT参考版.md` | +| ④ | 原型内嵌说明区（写进 `designs/<项目>/*.html` 自身）＋ 独立产品文档 `designs/<项目>/<产品项目名>.html` | + +### 文档的两态：当前版与过期版 + +用户令（2026-10-11 逐字）：「**应该有文件夹 专门归档过期文档， 当前文档 统一放在方案文件夹中**」。 + +🔴 **方案文件夹** ＝ `docs/pm/<项目>/` 这一层 —— 它下面放的全是**当前权威版**：①段 `research/`、②段 `prd/`、跨段 `专题/`，另加一份 `索引-当前权威版.md` 当入口。 + ⚠️ ③段与④段的产物**不在**文档根 —— 它们在设计根 `designs/<项目>/`（见上「产物落哪」）。⛔ 别按老口径去文档根下的 `ui/` 子目录找原型（那层已废，原型在设计根顶层与 `DESIGN.md` 同处）。 +🔴 **归档文件夹** ＝ `docs/pm/<项目>/归档-过期版/` —— 被顶替下来的旧版全放这里，命名 `<原名>__<来源目标短哈希>.<扩展名>`（例 `2b-界面布局-新版__fc471a.md`）。 +🔴 **设计根也有归档文件夹** ＝ `designs/<项目>/归档-过期版/` —— 收③段被替换下来的原型与④段的历史产品文档，命名带版本号或日期以便分辨。 + +**每个目标收口时做四步**： +1、本目标的权威文档**覆盖**方案文件夹里对应的那一份。 +2、被顶替的旧版**移进** `归档-过期版/`，按上面的命名补上来源短哈希。 +3、更新 `索引-当前权威版.md` 里对应行的大小与日期。 +4、执行区（`执行会话/目标-*/` 这类过程目录）里的原件**保留** —— 它既是过程留痕，也是台账 `artifact` 指向的地方，搬空会让回查断链。 + +**为什么要有这条**（避坑依据 · 2026-10-11 实测）：同一个 `2a-产品功能` 在 6 个目标目录里各有版本、`2b` 有 7 个，光看文件名与字节数分不出谁新；而 `docs/pm/` 下早先那次归档又停在旧版（`2b` 只 52 256 B，最新已是 52 643 B）⇒ 用户问「很多新老方案都在文件夹中，后续根据方案细化产品界面，如何找得到对应的方案」。判断某份文档的当前版，**只看方案文件夹**；问「当时为什么这么定」才去归档文件夹翻。 + +### DESIGN.md 为什么在项目目录、不在仓库根 + +`DESIGN.md` 是③段的绑定视觉规范，一个项目一份，③段按当前项目的 slug 去读它。仓库根只能放一份，多项目会互相覆盖，所以一律放 `designs/<项目>/DESIGN.md`（与原型同目录）。 + +推论（硬规则）：读 `DESIGN.md` 时，路径必须由本节定义的 `<项目>` slug 拼出，不许用「当前工作目录碰巧有 DESIGN.md」这类推断。仓库根不放任何项目的 `DESIGN.md`。 + +## 工具选择规则（防止选错，最重要的一节） + +> 下表是选型总则。这些工具都已封装在对应段内，本文件只负责让你不选错；具体调用路径见各段 `SKILL.md`。 + +| 要什么 | 用谁 | 别用 | +|---|---|---| +| 页面设计全链（规范 → 原型 → 审查） | ③段 `stage-delivery` 自己的 D0→D5 流水线 | 另找风格库，或自己手搓一套 token 与门禁 | +| 评审用的可点原型 / 生产级前端页面 | ③段 3b（按 D2 构建，单文件 HTML 交付）。先判页型：营销页取③段 §供给·版式骨架 的可选档，工具型页面取其默认档 | 不判页型就套可选档种子——那是营销落地页骨架，会把后台做成营销页 | +| 设计规范文件 | ③段 3a 生成 `DESIGN.md`（令牌表取自③段选定套，见③段 §供给·定调与令牌；再加该项目②段的界面需求） | 凭空编一套 token | +| 架构图 / 流程图 / 时序图 | `diagram-design` | 手写 Mermaid | +| 状态迁移的守卫、副作用、并发 | `state-machine` | 指望 diagram-design 覆盖这些 | +| 审美方向 / 风格定调 | ③段 §供给·定调与令牌 的默认档里选一套（可选档亦见该处），读候选套按页面类型挑。⛔ 每次只选一套 | 「米白＋衬线＋陶土色」这类默认审美，或凭感觉编 | +| 多方向比选 / 独立评审打分 | ③段 §供给·多方向比选 与 §供给·独立评审协议 | 拿它的评分循环替代本段 Gate-1/2/3 | + +③段的页面设计供给 —— 默认主线、定调与令牌、版式骨架、工艺数值判据、独立评审协议、多方向比选，共六档；各档的默认来源 / 可选来源 / 路径只在③段 `references/stage-delivery/SKILL.md` 的 §供给 定义一次，本入口不复述，要改供给只改那一块（2026-10-08 起）。`oil-ui-pro` 是界面设计方法论：五步流程（探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付），加风格对比页与截图工具；它自带联网版本检查与自动更新，是用户明确要求全量搬入的例外项（既有纪律是「依赖外部服务一律不收」），已记录在案，不扩散。 + +默认走 `oil-ui-pro` 主线，不与可选档缝成一条流水线：可选档只在 §供给 里列，选了才作补强（多一路定调候选、多一套工艺数值判据），不选也不影响开工。 + +四样东西供给件里都没有对应，由 `stage-delivery` 自己扛：设计契约十二字段、结构骨架、交互清单、工具型版式库。 + +页型分流（2026-10-05 新增）：③段 §供给·版式骨架 的可选档是营销落地页向，工具型页面照它做会长出「标题上下各一行小字」的三段式（骨架名单与理由见③段 `references/stage-delivery/references/layouts-tooling.md` 开头）。本项目实测踩过这个坑，结构判据全绿也拦不住。所以③段 D0 必须先判页型，工具型页面版式一律走 §供给·版式骨架 的默认档。 + +只读一处来源：同一条判据若在默认档与可选档各有一份且口径不同，以本项目追加条为准 —— ⛔ 但追加条不得放宽基础层（`oil-ui-pro` 是基础层、其余是叠加层，分层规则见③段 §供给），并在 runbook §3.4 显式标注「本项目追加」。 + +DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec` 四个子命令，目前是 alpha（v0.4.0）。非 TTY 的管道里可能不回显输出，需在真实终端里确认。本机实测该命令完全不可用，不要拿它当校验关卡；改由 D3 收口与 D5 终检按真实像素人工复测对比度（判据见③段 §供给·工艺数值判据 里配色那一份）。原两把门禁脚本（静态文案检查 / 渲染机检）已随旧主干从磁盘移除，当前没有机器复现，结论只能记「人工判定」，不得写成「脚本已通过」。 + +## 可调用工具（自然语言触发） + +> 两个独立工具，按用户说法直接触发，产物落项目目录。`design-capture` 随③段携带（装在③段 `references/stage-delivery/assets/` 下）；`video-capture` 2026-10-11 已独立成全局技能（装在**技能根**下的 `video-capture/`），跨段复用。两者都不单独成段。 + +| 用户说 | 触发工具 | 做什么 | 产物 | +|---|---|---|---| +| 「分析 XXX 视频」「把这个视频抽帧」「拆一下这条视频的画面」 | 全局技能 `video-capture` | 取视频（本地文件 / 直链 URL / 平台页经浏览器下到本地）＋ 抽帧（双因素 ＋ 首尾 ＋ 补帧） | 关键帧 `c_<序号>_<真实秒数>s.jpg` ＋ `frame_times.json`（供①竞品分析、③视觉参考） | +| 「获取 XXX 网站的设计风格」「抓这个网站的风格/组件/配色」 | `stage-delivery/assets/design-capture/` | 抓网页设计系统（色彩 / 排版 / 组件），生成样式模板 | 一套 `design-system-<名>/`（与 `design-system-tiaoyue` 同构，可直接被③段 D1 选用） | + +两者都独立可单跑：`video-capture` 只依赖 `ffmpeg`（权威件＝全局技能 `video-capture`；原 `stage-delivery/assets/video-capture/` 只留交接说明，脚本迁至 `references/_留痕/video-capture-已独立-20261011/` 留档）；`design-capture` 只依赖本机 Chrome（CDP）＋ `vendor/` 里搬运的抽取脚本，不需要任何外部服务在场。用法与边界见各自 `SKILL.md`，来源与署名见各自 `ATTRIBUTION.md`。 + +触发时机：①②段拆竞品视频用全局技能 `video-capture`；③段要新建样式或拆参考站用 `design-capture`。 + +两个工具都只做合规最小集：不抓平台页内视频，不调付费接口；抽取结果须先目视比对再采用。 + +## 进入方式 + +| 你说什么 | 模式 | 从哪开始 | +|---|---|---| +| 「规划 XX」「从零做 XX」 | 全流程（自动处理） | `stage-discovery` → `stage-requirements` → `stage-delivery` → `stage-proto-doc`，一路跑完，段间不停下来问（含①段末） | +| 「先确认方案」「跑完方案停下等我」「规划 XX，先给方案」 | 方案确认 | 同一套四段，唯一差别是①段末停下等你确认方案，确认后才进②③④ | +| 「只做产品需求」「只做产品功能」「只做界面交互」「只做原型说明文档」 | 单段 | 只调对应那一个 stage skill，不展开其他段 | +| 已有②段，要出原型 | 单段 | 直接调 `stage-delivery`，从它的 3a 起 | +| 已有原型，要补说明 | 单段 | 直接调 `stage-proto-doc`，从它的 4a 起 | +| 只问某个单点 | 单段 | 不跑任何段，在对应 stage skill 内点名子步，或直接说要看哪份方法论 | + +「只调一段」成立的原因：四段之间只通过落盘文件耦合，没有隐式状态。 + +- ②只读 `docs/pm/<项目>/research/*`；缺失时标注 `【假设】`继续，不催促回补① +- ③只读 `docs/pm/<项目>/prd/*`；缺失时同样标 `【假设】`继续 +- ④只读 `designs/<项目>/*.html`（界面事实的唯一依据），另按需读 `docs/pm/<项目>/prd/*` 与 `research/1a-需求文档.md` 定业务意图；缺失时标 `【假设】`继续，并在段末偏离单里写明 + +## 执行规则 + +只有三种模式，没有第四种： + +| 模式 | 段之间 | 段之内 | +|---|---|---| +| 全流程（自动处理） | 一路跑完，段间不停下来问（含①段末）。每段结束按「标准收尾格式」输出一段报告，输出完即刻进下一段 | 子步之间不反问，做完直接进下一个子步 | +| 方案确认 | 与全流程完全相同，只有一处不同：①段末停下等你确认方案；确认后②③④一路跑完、段间不停 | 同上 | +| 单段 | 不涉及 | 不越界，不催促回补前段 | + +这两条是全流程模式下的两个独立分支，不要混：全流程（自动处理）没有①段末的强制停；「停下等确认方案」只在「方案确认」模式下发生。二选一由用户定（界面里点【生成原型和文档】时选「自动处理」或「先确认方案」，或在会话里直接说明）；用户没明说时按自动处理走，不要在自动处理模式下自作主张停下来问。 + +「停下」指什么，不要读成「每一步都要反问用户」。只有这四种情况才停： + +1. 信息不足且查不到，必须用户给（如「项目与路径约定」slug 第 4 条）——停下问 +2. 破坏性 / 不可逆动作——二次确认 +3. 用户显式要求某个子步做完停下 +4. ①段末的方案确认（仅「方案确认」模式）——把方案摆给用户：做什么 / 不做什么 / MVP 边界 / 未复核的 `【假设】`，明说「等你确认方案，确认前不进②段」 + +段末报告：全流程（自动处理）模式下，所有段（含①）都只输出报告，不提问、不等回答；方案确认模式下①段是唯一例外，其余段同样只输出报告。 + +①段末的确认是回环，不是一次问答（仅「方案确认」模式）：用户看到方案后可以提问题要求改，可能多轮，每轮的「问题＋怎么改的」都要留痕、不得覆盖上一轮；改完由用户显式说「确认方案」才算过闸门。该模式下，没拿到用户确认的方案不得当成既定事实带进②段——这是实测踩过的坑：②段拿着未经确认的方案往下跑，把用户已拍板的需求裁掉了。 + +其余规则： + +- 声明制（全段适用，不止③段）：开工前、每进一个子段或子步、每处偏离，都要声明三件事——当前在哪、依据哪个文件的哪一节、产出落哪；偏离当场写明原因与影响，段末附偏离单。不许静默偏离。实测踩过的坑：③段 3b 交付了原型却没走当时声明的主流程、没读依据文件，也没当场说，用户追问「基于哪个 skill」才知道。 +- 不做八股：不介绍方法论来源，不列人名，不复述框架历史，直接给结论。 +- ⭐ 内容准则：一切落盘文字都要先过「说人话」这一关（2026-10-07 用户定案，同日扩大到规则文件）。用户原话：「当作第一步 和 第二步 生成文档时 必须遵循的内容准则」「不管是写规则 还是 写文档 都要严格按照说人话的技能去执行」。 + - 适用面两类都算，只改产出不改规则等于半改。一是产出文档：`research/1a-需求文档.md` 到 `1e-使用场景.md`（5 份）、`research/1b-独立分析/`（独立分析体）、`docs/pm/<项目>/prd/2a-产品功能.md` 与 `docs/pm/<项目>/prd/2b-界面布局.md`（2 份）。二是规则本身：本技能包内的一切落盘文字，`SKILL.md`、`references/**`、模板与清单。 + - 判据来源（单一可信源，本文件不复述模式清单）：**只有 `humanizer` 一份，且只用它的英文正式目录** —— `<技能根>/humanizer/references/patterns.md` 的 **P1–P55**（内容 8／语言与风格 10／沟通 3／填充与模糊 9／新兴 13／工艺与取证 12）。另有 5 种口吻档（casual / professional / technical / warm / blunt）。 + - 🔴 **判据一律用英文目录（2026-10-15 用户令）**：中文附录 `patterns.zh.md`（ZH1–ZH15）**只作参考线索，⛔ 不作判据** —— 作者自标「实验性、未经中文母语写手校验、不应被当作已验证的规则」。原中文版 `humanizer-zh` 的 24 条与五维 50 分表随该技能删除一并停用作废。 + - 门槛（2026-10-15 改）： + · **英文产出**：可读 `--score` 的 0–100 AI 痕迹密度分（越低越像人；上游 pre-commit 的拦截线是 40），本包不设硬阈值，分数写进段末报告。 + · **中文产出**：⛔ 不采信自动分数 —— 该打分器按 `[.!?]` 切句、按 `[a-z0-9]` 切词，中文 `。！？` 不切句、汉字零词，分数实际在测「文件里有多少拉丁字符」（实测：同一段中文把 `。` 换成 `. ` 分数不变；零拉丁字符的中文直接判 `No text`）。改按 **P1–P55 逐条人工对照**，再跑 `--check-facts` 保真（它只抽数字／日期／版本／URL／路径／标识符，中文同形可用）。对照结果与事实存活数写进段末报告，命中项不对完不许落盘。 + - ⛔ 取不到判据来源时（2026-10-08 补）：两份技能都不在位或读不到 ⇒ **不许凭感觉判「这条够人话」**。在段末报告与 3d 审查留痕件（`3d-审查报告.md` 或 `DESIGN.md` 审查节）里明写「无判据来源，本项未判」，按与 §供给·工艺数值判据 的「证据缺口」同一口径处理。 + - 五条核心原则（2026-10-15 起**就地固化在本包**；原引自已删除的 `humanizer-zh`《核心规则速查》，英文版 `humanizer` 的 Quick reference 没有等价条目，故不再指向外部）：删填充短语（开场白、强调性拐杖词）；打破公式结构（二元对比、戏剧性分段、修辞性设置）；变化节奏（长短交错，两项优于三项，段尾多样）；信任读者（直接陈述事实，跳过软化、辩解、手把手引导）；删金句（读起来像可引用的话，就重写它）。 + - 🔴 **适用面要划清（2026-10-15 排查后立）**：本包只取这份技能里**「去 AI 味」那一半**，⛔ 不取**「注入个性」那一半**。 + 取这些：英文模式目录 `references/patterns.md` 的 P1–P55、就地固化的五条核心原则、禁用清单。 + 不取这些：`Soul Injection Techniques` 整节（11 条）—— 它明写「有观点、别只报告事实」「用具体感官／体验细节代替抽象说法」「允许跑题与题外话」「结尾不必收束」「用 imperfect start 开场」，与本包产出要的**客观书面说明文**正好相反（照它写会出乱比喻、口水话、不能简明扼要）。该节第 3 条自带的示例就是「凌晨两点冷咖啡和看不懂的堆栈」这种感官化写法。 + 口吻档：本包产出**固定取 `technical`**（精确用词、一句一个意思、⛔ 无比喻除非确能澄清），⛔ 不用 casual／warm／blunt。 + ⛔ **已停用**：原中文版 `humanizer-zh` 及其五维 50 分表（该技能 2026-10-15 已整包删除，判据不再走它）。 + - 🔴 **同一件事更严的那份说了算**：④段的 `references/doc-language-spec.md`（客观书面说明文 ＋ 逐条禁用清单）是本包最严的一份语体规范；任一段落盘文字与它冲突，**以它为准**。 + - 交付留证：产出文档在段末报告里写明「已过内容准则，评分 X/50」；改规则文件时，在当日 memory 里记下这一关过了。 +- 只调一段时不越界：用户说「只做第 N 段」，就跑该段，不展开其他段，也不用「你还没做调研」去催促。 +- 提问上限 3 个：其余用合理假设，并在文档里标注 `【假设】`。例外是 `grill-me` 提问模式，不受此限（①段的「需求澄清」与②段的「需求压测」各一次），该模式的价值就是穷尽提问；此时须先声明「将连续多轮提问」，退出后恢复本约束。 +- 反问优先，允许自动补全：`grill-me` 的默认动作是把问题抛给用户并附推荐答案。用户说「你定」、连续两轮不回应、或属事实类问题时，模型自行给答案并标 `【假设】`，换来「不卡住」；但每轮结束要汇出待复核清单，未经复核的 `【假设】` 不得在下游当事实用。 +- 停线规则（**单一真源，全包只在本节写一次**，各段一律引用、⛔ 不复述）：只有三种情况停 —— ① 信息不足且查不到；② 破坏性／不可逆动作；③ 用户显式要求。 +- MVP 边界优先：任何阶段都先回答「第一版做什么、不做什么」。 +- 必须落盘：产出写入文件，不要只在对话里输出。 +- 无来源就标注：任何查不到来源的数据都标为「估算」并写明口径，不编造数字当事实。 +- 禁止长文：单份产出物默认一页纸（≤120 行），超长必须拆分。 +- ⭐ 落盘产出的排版（2026-10-14 用户令，原话「标题周围写小字的怪毛病 彻底改掉」）：元信息（条数、口径、读法、状态）写进表格的列、条目的字段或表头；标题旁边、标题下面、标题后面都只放标题本身。④段的 `references/doc-language-spec.md` 另有一份更细的，冲突以那份为准。 +- 🔴 路径写相对或占位（2026-10-14 用户令）：本包内一切文字（`SKILL.md`、`references/**`、脚本与注释、模板）引用**本技能自己或同根技能**的位置时，写相对形态 —— 同根技能写 `<技能根>/<技能名>/`，本包自己的文件写包内相对路径（如 `references/stage-delivery/`）。只有**跨根引用**（工作区根、文档库根、本机软件安装位这类从本包推不出来的别的根）才落到具体位置，且优先读环境变量（`DSH_WS_ROOT` / `DSH_DOCS_ROOT` / `WORKBUDDY_BIN_ROOT`）。原因：技能根的位置随环境变（全局技能根还是工作区技能根、用户名与盘符各不相同），写死了换台机器就是死路径，跨环境会整片报错。 + +## 征询外部模型（GPT）的提问口径（单一真源） + +> 🔴 2026-10-15 用户令，逐字：「问 GPT 的时候 只需要说明 关键背景情况和需求询问，禁止带入过多细节上下问造成干扰」。本包内一切向外提问的动作都按本节写；③段 3c 的提问模板是本节的一个实例，⛔ 不在别处另立一套口径。 + +- **要写三样**：① 场景一句（这是什么、要解决什么）；② 手上已有什么（只列与本次提问有关的）；③ 想问哪几个问题（逐条列，一条一个问点，末尾一句收口）。 +- **判据**：背景写到「对方能接住这个问题」为止 —— 少了这句，对方就问不出对的问题吗？问不出才留，问得出就删。 +- **⛔ 不带**：过程留痕、已废弃做法的设计细节、「我们为什么这么做」的来龙去脉、内部硬约束清单、字段与文件清单。这些会把回答拖进细节纠缠，占掉本该用在核心问题上的注意力。 +- **为什么**（避坑依据 · 2026-10-14 实测）：为问「原型说明文档该怎么写」，先铺了 1 500 余字的背景（含已废弃做法的 5 个设计点、4 条硬约束、7 个问题）⇒ 细节量压过问题本身。 +- **留痕**：提问原文与回答原文都要落盘；提问按本节写，⛔ 不把本机路径当内容（外部模型看不到本机路径，要么逐字内联、要么上传文件）。 + +## 产出文档开头必须有图（单一真源） + +> 2026-10-15 用户令，逐字：「产品规划页面 所有文档前面都要画图」。各段一律引用本节，⛔ 不在段内另写一套口径。 + +- 每份落盘文档**第一屏就给一张图**：图放在标题之后、正文之前 —— 不读正文也能先拿到全貌。 +- 图是**正文内容**，⛔ 不写成标题旁边或标题下面的注解小字（与上面那条排版红线同一件事）。 +- 图要**表达结构或流程**（二选一或兼具）—— 一张图看完就知道「由哪几块组成、怎么连起来」或「一件事分几步走」；⛔ 不做纯装饰性配图。 +- 图表达这份文档**覆盖的东西之间的关系**，按段定画什么： + · ①段（`research/` 五份）—— 画对象与流向：为谁解决什么、信息从哪来到哪去。 + · ②段（文档根 `docs/pm/<项目>/prd/` 两份）—— 画页面骨架：有哪几页、每页几个板块、跨页关系怎么走。 + · ③段（`ui/` 下的产物与 `DESIGN.md`）—— 画页面结构与操作动线：用户办成一件事实际经过哪几页、每页做什么、哪里要来回跳。 + · ④段（产品文档）—— 画页面结构图（各页面与其下的功能编号）＋ 用户路径：各场景怎么串起来。 +- 画图用 `diagram-design`，⛔ 不手写 Mermaid（判据见「工具选择规则」那张表）。 +- 图里每格写清名字、线标方向；图与正文互相对得上 —— 正文新增或改了结构，图要跟着改，两处不许各说各的。 + +## 每段的标准收尾格式 + +``` +## 本段结论 +- （3-5 条，可直接决策的话） + +## 已落盘 +- ... + +## 待确认（最多 3 条） + +## 建议下一步 +→ 用 完成 <具体事> +``` + +## 反面清单 + +- 为一个小功能跑完整调研 +- 输出长文却给不出一个结论 +- 跳过「不做什么」 +- 用户只问单点，却强行拉进全链路 +- 把估算数据写成确凿事实 +- 跳过③段 D0 的 Gate-1（未定死令牌表与设计契约）就开写页面代码 +- 在 `grill-me` 提问模式下仍套用「提问上限 3 个」，把提问做成走过场 +- 只跑一次 `grill-me`：①没定义需求就去取证，或②拿①段的需求定义代替功能压测直接写②段 +- 把自动补全当默认动作：用户没说话就替用户拍板，还没标 `【假设】`、没进待复核清单 +- 手写 Mermaid 代替 diagram-design，手写 token 表代替 DESIGN.md +- 绕过四段自己手搓，或重写它们的内容（该调 `stage-*` 就调） +- 把供给件的内部路径按本 skill 目录去拼，或改它们的正文 —— 供给件指③段自带的 `oil-ui-pro`，以及 §供给 各档落在 `assets/` 下的件（它们是随③段携带的供给件，改动只写 `stage-delivery` 自己的 `SKILL.md` / `references/`；默认档与可选档平行，不缝成一条流水线，也不把 `oil-ui-pro` 的评分循环当成本段 Gate 的替代） +- 猜 `<项目>`：定不出来还硬写，把产物落到别的项目目录下 +- 把 `DESIGN.md` 写到仓库根：多项目会互相覆盖 +- 段间停下来问「要不要继续」：全流程（自动处理）模式下直接进下一段，只在段末输出报告 +- 把两种模式混用：在自动处理模式下自作主张停下问方案，或在「方案确认」模式下确认前就开跑②③④ +- 在「方案确认」模式下把①段的方案当成已确认就往下跑：该模式下①段末必须停下等用户确认（含「不做什么」） +- 下游擅自裁剪上游已拍板项：②③④发现要砍①段或决策表里已拍板的东西时，不许自行裁掉或改口径，必须列成「与已定决策的差异」交用户显式确认 +- 把模式当成段：模式是「要不要在①段末停」的开关，不是第五个段，别为它单独造段或造产物 +- 跑了却不说：没声明当前段 / 子步与依据文件，或偏离了被调 skill 的主流程却不声明、不记偏离单（应为：开工先声明、每个子步再声明、偏离当场声明） +- 让③段顺手把说明区或产品文档写了（那是第④段 `stage-proto-doc` 的活） +- ④段里重新规划产品、重新设计界面，或写原型上没有的页面 / 功能 / 业务规则（④段只解释与记录**现有**原型） +- 问外部模型时堆砌背景：把过程留痕、废弃做法、内部约束清单整段贴进去（应按「征询外部模型（GPT）的提问口径」只给关键背景 ＋ 明确问题） +- 落盘文档开头不给图，或图与正文各说各的（应按「产出文档开头必须有图」先上图、再写正文，两处对得上） +- 过「说人话」时把「注入个性」那半也照做：加观点、加第一人称、写感官细节与比喻、允许跑题（应按内容准则只取「去 AI 味」那半，产出仍是客观书面说明文） + +## 改名 / 改供给后的自检 + +```bash +python scripts/check_naming.py --ws <工作区> +``` + +它查四段段名与子步名在「总入口 ↔ 各段 `SKILL.md` ↔ 各段 `references/`」之间有没有漂，包括 H1 与子步表是否一致、总入口子步列有没有漏项、runbook 必读表有没有引用已移除的资产、两份副本是否一致。纯静态比对，不需要渲染，不需要外部依赖。 + +为什么必须有它：实测当天漏过两次，当时没有任何门禁会报错。 + +第一次（2026-10-02）：改段名时 `SKILL.md` 改了，但 `references/stage-discovery/references/grill-me.md` 的 H1 仍写「需求澄清（grill-me · 调研段）」；`references/stage-requirements/SKILL.md` 子步表写「2b 功能流转」而正文 H2 写「## 2b 状态机」；总入口④段子步列只写「4a 说明区 / 演示引导」漏了 4b / 4c。三处都只能靠回读发现。 + +第二次（2026-10-06）：②段收窄为「只细化功能」（7 份产出变 1 份）后，各段 `SKILL.md` 都改了，但总入口的三处仍写着旧结构——四段表的②段子步列仍是「2a 功能定义与压测 / 2b 功能流转 / 2c 功能图示」，四段表的①段子步列「1c 产品定位与商业设计」未随段内改名（段内已改称「产品定位与场景」），正文仍写「①与②各跑一次 `grill-me`」并指向两份同名文档，实际全场只有①段一份。闸门当场报 6 个 FAIL，根因是「改了承载段、忘了总入口」。 + +由此立一条硬纪律，与「换供给不能只改承载段」同型：凡改子步结构 / 段内产出清单 / 段间交接口，必须连带改总入口 `product-planning/SKILL.md` 的「四段结构」表与「交接口」表，不改就是半改状态。 + +改了段名 / 子步名 / 判据供给源之后必须跑一次，并把结果记进当日 memory。改完不校验，下次读契约的人拿到的是错的配方。 + +本脚本只查文本一致性（H1 ↔ 子步表 ↔ 总入口 ↔ 副本），查不出「判据口径是否自相矛盾」。例如「②段到底该不该给页面结构」这种反转，闸门一个字都报不出来。口径类改动要靠人工回读，且必须把反转理由与用户原话写进文档留痕。 + +脚本输出里的 `[提示]` 项（旧名出现）不计入失败，但要人工看一眼是不是落在「废止理由块」里——落在里面是正当留痕，散落在正文里就是真残留。 + +2026-10-07 起本技能只在全局一份：技能根下的 `product-planning/`。它就是本体，不再有「主 / 副 / 装入」三副本，也不再需要「三处 md5 复核」（那只在有副本时才有意义）。改完只跑一次 `check_naming.py --ws <工作区>`。用户原话：「把产品规划复制到 workbuddy 全局skills中 后续维护和使用全局技能」。工作区原先那三份已归档到 `归档/技能迁全局-20261007/`（未直删，可随时取回）。 diff --git a/product-planning/references/_留痕/SKILL-总入口-20261016技能级assets前.md b/product-planning/references/_留痕/SKILL-总入口-20261016技能级assets前.md new file mode 100644 index 0000000..013d456 --- /dev/null +++ b/product-planning/references/_留痕/SKILL-总入口-20261016技能级assets前.md @@ -0,0 +1,322 @@ +--- +name: product-planning +description: 产品规划总入口（唯一入口），四段式调度：① 产品需求 ② 产品功能 ③ 界面交互 ④ 原型说明文档。四段以 references/stage-* 承载，本文件是总调度与约束。可整段跑也可只调一段。当用户要做产品规划、从零做新产品、只做某一阶段、或不知道从哪开始时调用。 +--- + +# 产品规划总入口 + +> 本 skill 由模型按需自动加载，没有斜杠命令。对话里还没定出对象时，先按「项目与路径约定」定出 `<项目>`；定不出来就停下问用户，不要自行假设。 + +## 用途 + +用户丢来一句模糊想法（例如「我要做一个 AI 短剧分镜画布」）时，本 skill 判断该走哪一段，只做那一段的最小必要工作，产出可交付物，再推进到下一段。 + +本文件管调度与约束。各段怎么做，写在 `references/stage-*` 各自的文件里。 + +## 四段结构（可整段跑，也可只调一段） + +| 段 | 回答的问题 | 子步 | 调用 | 产出物 | +|---|---|---|---|---| +| **① 产品需求** | 要做的东西凭什么成立：什么问题、为谁、为什么值得做 | 1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景 | `stage-discovery` | `产品规划/research/*`。其中 1b 交两种体例：`research/1b-竞品分析.md`（汇总对比）＋ `research/1b-独立分析/<竞品名>.md`（独立分析） | +| **② 产品功能** | 要做哪些功能、什么不做、长成什么骨架 | 2a 产品功能 / 2b 界面布局 | `stage-requirements` | `产品规划/prd/2a-产品功能.md` 与 `产品规划/prd/2b-界面布局.md`（两份） | +| **③ 界面交互** | 长什么样、怎么操作 | 3a 视觉规范 / 3b 原型 / 3c GPT参考版 / 3d 审查打磨 | `stage-delivery` | `产品原型/designs/DESIGN.md`、`产品原型/pages/*.html`、`产品原型/designs/3c-GPT参考版.md` | +| **④ 原型说明文档** | 现有原型怎么用、每条功能落在哪个页面、坏了怎样、怎么核对（文档按七节铺：原型地址 → 页面结构 → 功能清单 → 使用场景 → 操作流程 → 页面导航 → 原型状态取值） | 4a 场景盘点 / 4b 说明区 / 4c 演示引导（可选） | `stage-proto-doc` | 原型内嵌说明区 ＋ 独立产品文档 `产品原型/pages/<产品项目名>.html`（两份共用同一套 P 页面／S 场景／F 功能／J 二级功能编号） | + +四段只通过落盘文件耦合。段间交接口如下，这是唯一的契约，越界即失效： + +| 交接 | 由谁给 | 给什么 | 给到哪为止 | +|---|---|---|---| +| ① → ② | ① | 问题定义、需求澄清决策表（含 grill 压测的 B 节：做成什么样 / 哪些情况不成立 / 状态怎么流转）、取证结论（1b 汇总对比体 ＋ 1b 独立分析体、1c 用户画像）、产品定位、《使用场景》＝用户故事（②段功能的直接推导依据） | 功能清单归②段产出，1a 写到需求与形态为止 | +| ② → ③ | ② | 功能清单（每条带优先级 ＋ 状态流转）、界面布局（有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系）、每页主操作、信息承载分档（主屏常驻 / 可点入） | 视觉归③段。骨架必须给全，骨架不给全，③段就一版一个样 | +| ③ → ④ | ③ | 已跑通的单文件原型 HTML（页面、模块、控件、状态、交互、跳转、反馈＝界面事实的唯一依据） | 说明区与独立产品文档归④段；⛔ ④段不重新规划产品、不重新设计界面 | + +> 口径：②段钉骨架，③段做皮肉。两侧逐行对照与用户原话只在②段 `references/stage-requirements/SKILL.md` 的 §②—③ 交接口 定义一次 —— 本入口不复述。要点两条：②段要给全「归②段」列；③段不许增删移动板块，缺板块回②段改。 + +> ②→③ 最容易搞坏。旧病灶：②段说「必须能读到」，③段读成「必须常驻主屏」，五类信息就全铺一屏成了信息墙。分档表把「读到」明确成「一次点击内可达」，防的就是这句歧义。骨架是灰块（有哪些块、什么顺序），③段给的是视觉与交互实现（排版、点哪有什么反馈、空态、响应式）。两件事各管一维，③段不会退化成照抄。 + +> 四段各占一个词，互不共用（2026-10-02 定）：产品 / 功能 / 界面 / 说明。改段名前先对照这张表；两个段名里出现同一个词，边界一定在漂。旧名「调研与方案 / 需求与结构」都含「需求」，③段旧名里的「交付」是三段共有的属性，都属名实不符，已改。 +> 🔴 **④段的沿革（2026-10-14 → 10-15）**：10-14 按用户令删掉**旧版**④段 —— 旧做法是往原型 HTML 注入说明区注解层（状态 → 场景 → 从左到右流程图 → 功能作用/输入边界/异常情况 三段 → 逐步骤演示引导），实测没法用，整段连方法论一并撤掉。10-15 用备份里的**新版**④段装上：改成「解释与记录现有原型」，交**两份产物**（原型内嵌说明区 ＋ 独立产品文档 `产品原型/pages/<产品项目名>.html`），内容先按四块＋附录铺，随后整套同步成**七节**（原型地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值），编号改用 P 页面／S 场景／F 功能／J 二级功能，并带一份现成模板 `references/stage-proto-doc/assets/产品文档模板.html`。判据正文在 `references/stage-proto-doc/`，⛔ 旧版那套（状态轴、三段必填、逐步骤演示）不再使用。 +> ①叫「产品需求」不叫「需求调研」：该段产出 `research/1a-需求文档.md`、`1b-竞品分析.md`、`1c-用户画像.md`，也产出 `1d-产品策略.md`、`1e-使用场景.md`，「调研」二字盖不住后半截。 +> ⭐ 1b 是①段唯一交两种体例的子步：独立分析体 `research/1b-独立分析/<竞品名>.md`（竞品池每一个一份），汇总对比体 `research/1b-竞品分析.md`（恒一份）。职责边界与定案原话见 `references/stage-discovery/references/competitor-analysis.md` §0.4。 + +⭐ `grill-me` 全场只有①段一份（2026-10-06 用户定案）：①段那份按 A / B 两节提问，火力点划分、节次归属与定案原话见 `references/stage-discovery/references/grill-me.md` —— ⛔ 本入口不复述。B 节结论落进 `research/1a-需求文档.md`。 + +⭐ ②段产出两份（2026-10-06 收窄，2026-10-07 定为两份）：`产品规划/prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 ＋ 状态流转）与 `产品规划/prd/2b-界面布局.md`（页面关系 ＋ 页面内板块布局）。定案原话与理由见 `references/stage-requirements/SKILL.md` 开头。 + +（交接口反转前的口径、②段收窄前的产出清单与去向 → `references/_留痕/③段与总入口-旧口径.md`） + +⚠️ ①段功能按「使用场景」组织（一条场景可跨多个页面），不按页面组织。 + +段内的子步顺序、方法论文档、硬约束、完成标准，都在各段自己的 `SKILL.md` 与 `references/` 里。 + +①段 1a 需求文档：全程最先做，且只做一次。用 grill-me 与用户互动，产出 `产品规划/research/1a-需求文档.md`（开头写清做什么 / 为谁 / 不做什么，往下是决策表）。 + +## 项目与路径约定（单一真源） + +> 四段全部遵守本节。**产品根** ＝ 同时含 `产品规划/` 与 `产品原型/` 的那一层目录（例 `<工作区>/项目/script-shortvideo/`）。各段 `SKILL.md` 与 `references/` 里的 `产品规划/...`、`产品原型/...` 一律**相对产品根**读。 + +### 目录长什么样 + +工作区顶层只放 `项目/`｜`调研/`｜`复盘/`（外加机制自己的 `tmp/`、`交付物/`、`执行会话/`、`.workbuddy/`、`.registry/`）。 + +`项目/` 下是**产品文件夹**，一个产品一层，目录名就是产品 slug（小写字母、数字、连字符，例 `my-tool`、`script-shortvideo`）—— 这个目录就是**产品根**。产品根下三个落点： + +| 根 | 路径 | 装什么 | +|---|---|---| +| 🔴 **文档根** | `产品规划/` | ①段 `research/`（`1a`~`1e`）、②段 `prd/`（`2a-产品功能.md` ／ `2b-界面布局.md`）、跨段 `专题/` | +| 🔴 **设计根** | `产品原型/designs/` | ③段 `DESIGN.md` ＋ `3c-GPT参考版.md` ＋ 3d 审查留痕件 ＋ 截图 `_gate_shots/` | +| 🔴 **页面根** | `产品原型/pages/` | ③段原型 `*.html` ＋ ④段独立产品文档 `<产品项目名>.html` ＋ 页面用静态资源 | + +⚠️ **②段 prd 归文档根**，⛔ 不跟③段一起搬 —— 它与①段 `research/` 同根，③段的机检脚本也按 `产品规划/prd/2b-*.md` 去定位它（`find_doc`）。⛔ 已废的那层 `ui/` 子目录不要再写进任何判据。 +⚠️ **原型页面不放在设计根**（放在页面根 `产品原型/pages/`）：③段的机检脚本按 `产品原型/pages/*.html` 找原型（`find_proto`）。⛔ 原型 HTML 一律落页面根，设计根只留规范与参考件。 + +### slug 怎么定（按序取第一个成立的） + +| 序 | 条件 | 取值 | +|---|---|---| +| 1 | 用户在当前会话里明确说了项目名 | 该名字 slug 化 | +| 2 | `.registry/current-project` 存在且非空 | 其内容 | +| 3 | `项目/` 下恰有一个非 `_` 开头的目录 | 该目录名（＝产品根名） | +| 4 | 以上都不成立 | 停下问用户 | + +写任何文件之前先核对：目标路径里产品根那一段的目录名与按上表得出的 slug 是否一致。不一致就停下说明，不要「先写了再说」——猜错会把产物写进别的项目，事后极难拆干净。 + +### 产物落哪 + +| 段 | 路径 | +|---|---| +| ① 产品需求 | `产品规划/research/` | +| ② | `产品规划/prd/` | +| ③ | `产品原型/designs/DESIGN.md`、`产品原型/pages/*.html`、`产品原型/designs/3c-GPT参考版.md` | +| ④ | 原型内嵌说明区（写进 `产品原型/pages/*.html` 自身）＋ 独立产品文档 `产品原型/pages/<产品项目名>.html` | + +### 文档的两态：当前版与过期版 + +用户令（2026-10-11 逐字）：「**应该有文件夹 专门归档过期文档， 当前文档 统一放在方案文件夹中**」。 + +🔴 **方案文件夹** ＝ `产品规划/` 这一层 —— 它下面放的全是**当前权威版**：①段 `research/`、②段 `prd/`、跨段 `专题/`，另加一份 `索引-当前权威版.md` 当入口。 + ⚠️ ③段与④段的产物**不在**文档根 —— 规范类在设计根 `产品原型/designs/`、页面类在页面根 `产品原型/pages/`（见上「产物落哪」）。⛔ 别按老口径去文档根下的 `ui/` 子目录找原型（那层已废）。 +🔴 **归档文件夹** ＝ `产品规划/归档-过期版/` —— 被顶替下来的旧版全放这里，命名 `<原名>__<来源目标短哈希>.<扩展名>`（例 `2b-界面布局-新版__fc471a.md`）。 +🔴 **设计根与页面根也各有归档文件夹** ＝ `产品原型/designs/归档-过期版/` 与 `产品原型/pages/归档-过期版/` —— 前者收被替换下来的设计规范与参考件，后者收被替换下来的原型页面与历史产品文档；命名带版本号或日期以便分辨。 + +**每个目标收口时做四步**： +1、本目标的权威文档**覆盖**方案文件夹里对应的那一份。 +2、被顶替的旧版**移进** `归档-过期版/`，按上面的命名补上来源短哈希。 +3、更新 `索引-当前权威版.md` 里对应行的大小与日期。 +4、执行区（`执行会话/目标-*/` 这类过程目录）里的原件**保留** —— 它既是过程留痕，也是台账 `artifact` 指向的地方，搬空会让回查断链。 + +**为什么要有这条**（避坑依据 · 2026-10-11 实测）：同一个 `2a-产品功能` 在 6 个目标目录里各有版本、`2b` 有 7 个，光看文件名与字节数分不出谁新；而 `产品规划/` 下早先那次归档又停在旧版（`2b` 只 52 256 B，最新已是 52 643 B）⇒ 用户问「很多新老方案都在文件夹中，后续根据方案细化产品界面，如何找得到对应的方案」。判断某份文档的当前版，**只看方案文件夹**；问「当时为什么这么定」才去归档文件夹翻。 + +### DESIGN.md 为什么在产品根、不在工作区根 + +`DESIGN.md` 是③段的绑定视觉规范，一个产品一份，③段按产品 slug 去读它。工作区根只能放一份，多产品会互相覆盖，所以一律放 `产品原型/designs/DESIGN.md`。 + +推论（硬规则）：读 `DESIGN.md` 时，路径必须由本节定义的**产品根**拼出，不许用「当前工作目录碰巧有 DESIGN.md」这类推断。工作区根不放任何产品的 `DESIGN.md`。 + +## 工具选择规则（防止选错，最重要的一节） + +> 下表是选型总则。这些工具都已封装在对应段内，本文件只负责让你不选错；具体调用路径见各段 `SKILL.md`。 + +| 要什么 | 用谁 | 别用 | +|---|---|---| +| 页面设计全链（规范 → 原型 → 审查） | ③段 `stage-delivery` 自己的 D0→D5 流水线 | 另找风格库，或自己手搓一套 token 与门禁 | +| 评审用的可点原型 / 生产级前端页面 | ③段 3b（按 D2 构建，单文件 HTML 交付）。先判页型：营销页取③段 §供给·版式骨架 的可选档，工具型页面取其默认档 | 不判页型就套可选档种子——那是营销落地页骨架，会把后台做成营销页 | +| 设计规范文件 | ③段 3a 生成 `DESIGN.md`（令牌表取自③段选定套，见③段 §供给·定调与令牌；再加该项目②段的界面需求） | 凭空编一套 token | +| 架构图 / 流程图 / 时序图 | `diagram-design` | 手写 Mermaid | +| 状态迁移的守卫、副作用、并发 | `state-machine` | 指望 diagram-design 覆盖这些 | +| 审美方向 / 风格定调 | ③段 §供给·定调与令牌 的默认档里选一套（可选档亦见该处），读候选套按页面类型挑。⛔ 每次只选一套 | 「米白＋衬线＋陶土色」这类默认审美，或凭感觉编 | +| 多方向比选 / 独立评审打分 | ③段 §供给·多方向比选 与 §供给·独立评审协议 | 拿它的评分循环替代本段 Gate-1/2/3 | + +③段的页面设计供给 —— 默认主线、定调与令牌、版式骨架、工艺数值判据、独立评审协议、多方向比选，共六档；各档的默认来源 / 可选来源 / 路径只在③段 `references/stage-delivery/SKILL.md` 的 §供给 定义一次，本入口不复述，要改供给只改那一块（2026-10-08 起）。`oil-ui-pro` 是界面设计方法论：五步流程（探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付），加风格对比页与截图工具；它自带联网版本检查与自动更新，是用户明确要求全量搬入的例外项（既有纪律是「依赖外部服务一律不收」），已记录在案，不扩散。 + +默认走 `oil-ui-pro` 主线，不与可选档缝成一条流水线：可选档只在 §供给 里列，选了才作补强（多一路定调候选、多一套工艺数值判据），不选也不影响开工。 + +四样东西供给件里都没有对应，由 `stage-delivery` 自己扛：设计契约十二字段、结构骨架、交互清单、工具型版式库。 + +页型分流（2026-10-05 新增）：③段 §供给·版式骨架 的可选档是营销落地页向，工具型页面照它做会长出「标题上下各一行小字」的三段式（骨架名单与理由见③段 `references/stage-delivery/references/layouts-tooling.md` 开头）。本项目实测踩过这个坑，结构判据全绿也拦不住。所以③段 D0 必须先判页型，工具型页面版式一律走 §供给·版式骨架 的默认档。 + +只读一处来源：同一条判据若在默认档与可选档各有一份且口径不同，以本项目追加条为准 —— ⛔ 但追加条不得放宽基础层（`oil-ui-pro` 是基础层、其余是叠加层，分层规则见③段 §供给），并在 runbook §3.4 显式标注「本项目追加」。 + +DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec` 四个子命令，目前是 alpha（v0.4.0）。非 TTY 的管道里可能不回显输出，需在真实终端里确认。本机实测该命令完全不可用，不要拿它当校验关卡；改由 D3 收口与 D5 终检按真实像素人工复测对比度（判据见③段 §供给·工艺数值判据 里配色那一份）。原两把门禁脚本（静态文案检查 / 渲染机检）已随旧主干从磁盘移除，当前没有机器复现，结论只能记「人工判定」，不得写成「脚本已通过」。 + +## 可调用工具（自然语言触发） + +> 三个独立工具，按用户说法直接触发，产物落项目目录。`design-capture` 与 `element-picker` 随③段携带（都装在③段 `references/stage-delivery/assets/` 下）；`video-capture` 2026-10-11 独立成全局技能（装在**技能根**下），跨段跨项目复用。三者都不单独成段。 + +| 用户说 | 触发工具 | 做什么 | 产物 | +|---|---|---|---| +| 「分析 XXX 视频」「把这个视频抽帧」「拆一下这条视频的画面」 | 全局技能 `video-capture` | 取视频（本地文件 / 直链 URL / 平台页经浏览器下到本地）＋ 抽帧（双因素 ＋ 首尾 ＋ 补帧） | 关键帧 `c_<序号>_<真实秒数>s.jpg` ＋ `frame_times.json`（供①竞品分析、③视觉参考） | +| 「获取 XXX 网站的设计风格」「抓这个网站的风格/组件/配色」 | `stage-delivery/assets/design-capture/` | 抓网页设计系统（色彩 / 排版 / 组件），生成样式模板 | 一套 `design-system-<名>/`（与 `design-system-tiaoyue` 同构，可直接被③段 D1 选用） | +| 「选中这个组件」「把这个元素的位置给你」「改这个页面的样式」「这个按钮在哪」 | `stage-delivery/assets/element-picker/` | 在浏览器里点选任意组件，取出它的 CSS 选择器与所属网页，交给 AI 定位源码改样式 | 剪贴板两行（`选择器：…` / `网页：…`）＋ 存档 `marks/_ui-marks.json`（含文本 / class / 属性 / 尺寸 / 关键样式 / HTML 片段） | + +三者都独立可单跑：`video-capture` 只依赖 `ffmpeg`（权威件＝全局技能 `video-capture`；原 `stage-delivery/assets/video-capture/` 只留交接说明，脚本迁至 `references/_留痕/video-capture-已独立-20261011/` 留档）；`design-capture` 只依赖本机 Chrome（CDP）＋ `vendor/` 里搬运的抽取脚本，不需要任何外部服务在场；`element-picker` 只依赖 Node 标准库起一个本地服务（默认 8890，扩展那一路装一次即对所有网页可用）。用法与边界见各自 `SKILL.md`（第三方来源与署名见各自的 `ATTRIBUTION.md`）。 + +触发时机：①②段拆竞品视频用全局技能 `video-capture`；③段要新建样式或拆参考站用 `design-capture`；③段以及任何"用户指着一个组件说改这里"的场合用 `element-picker`。 + +两个抓取类工具（`video-capture`、`design-capture`）都只做合规最小集：不抓平台页内视频，不调付费接口；抽取结果须先目视比对再采用。`element-picker` 不抓取任何数据，只读当前页面自身的 DOM、把结果落在本地文件。 + +## 进入方式 + +| 你说什么 | 模式 | 从哪开始 | +|---|---|---| +| 「规划 XX」「从零做 XX」 | 全流程（自动处理） | `stage-discovery` → `stage-requirements` → `stage-delivery` → `stage-proto-doc`，一路跑完，段间不停下来问（含①段末） | +| 「先确认方案」「跑完方案停下等我」「规划 XX，先给方案」 | 方案确认 | 同一套四段，唯一差别是①段末停下等你确认方案，确认后才进②③④ | +| 「只做产品需求」「只做产品功能」「只做界面交互」「只做原型说明文档」 | 单段 | 只调对应那一个 stage skill，不展开其他段 | +| 已有②段，要出原型 | 单段 | 直接调 `stage-delivery`，从它的 3a 起 | +| 已有原型，要补说明 | 单段 | 直接调 `stage-proto-doc`，从它的 4a 起 | +| 只问某个单点 | 单段 | 不跑任何段，在对应 stage skill 内点名子步，或直接说要看哪份方法论 | + +「只调一段」成立的原因：四段之间只通过落盘文件耦合，没有隐式状态。 + +- ②只读 `产品规划/research/*`；缺失时标注 `【假设】`继续，不催促回补① +- ③只读 `产品规划/prd/*`；缺失时同样标 `【假设】`继续 +- ④只读 `产品原型/pages/*.html`（界面事实的唯一依据），另按需读 `产品规划/prd/*` 与 `research/1a-需求文档.md` 定业务意图；缺失时标 `【假设】`继续，并在段末偏离单里写明 + +## 执行规则 + +只有三种模式，没有第四种： + +| 模式 | 段之间 | 段之内 | +|---|---|---| +| 全流程（自动处理） | 一路跑完，段间不停下来问（含①段末）。每段结束按「标准收尾格式」输出一段报告，输出完即刻进下一段 | 子步之间不反问，做完直接进下一个子步 | +| 方案确认 | 与全流程完全相同，只有一处不同：①段末停下等你确认方案；确认后②③④一路跑完、段间不停 | 同上 | +| 单段 | 不涉及 | 不越界，不催促回补前段 | + +这两条是全流程模式下的两个独立分支，不要混：全流程（自动处理）没有①段末的强制停；「停下等确认方案」只在「方案确认」模式下发生。二选一由用户定（界面里点【生成原型和文档】时选「自动处理」或「先确认方案」，或在会话里直接说明）；用户没明说时按自动处理走，不要在自动处理模式下自作主张停下来问。 + +「停下」指什么，不要读成「每一步都要反问用户」。只有这四种情况才停： + +1. 信息不足且查不到，必须用户给（如「项目与路径约定」slug 第 4 条）——停下问 +2. 破坏性 / 不可逆动作——二次确认 +3. 用户显式要求某个子步做完停下 +4. ①段末的方案确认（仅「方案确认」模式）——把方案摆给用户：做什么 / 不做什么 / MVP 边界 / 未复核的 `【假设】`，明说「等你确认方案，确认前不进②段」 + +段末报告：全流程（自动处理）模式下，所有段（含①）都只输出报告，不提问、不等回答；方案确认模式下①段是唯一例外，其余段同样只输出报告。 + +①段末的确认是回环，不是一次问答（仅「方案确认」模式）：用户看到方案后可以提问题要求改，可能多轮，每轮的「问题＋怎么改的」都要留痕、不得覆盖上一轮；改完由用户显式说「确认方案」才算过闸门。该模式下，没拿到用户确认的方案不得当成既定事实带进②段——这是实测踩过的坑：②段拿着未经确认的方案往下跑，把用户已拍板的需求裁掉了。 + +其余规则： + +- 声明制（全段适用，不止③段）：开工前、每进一个子段或子步、每处偏离，都要声明三件事——当前在哪、依据哪个文件的哪一节、产出落哪；偏离当场写明原因与影响，段末附偏离单。不许静默偏离。实测踩过的坑：③段 3b 交付了原型却没走当时声明的主流程、没读依据文件，也没当场说，用户追问「基于哪个 skill」才知道。 +- 不做八股：不介绍方法论来源，不列人名，不复述框架历史，直接给结论。 +- ⭐ 内容准则：一切落盘文字都要先过「说人话」这一关（2026-10-07 用户定案，同日扩大到规则文件）。用户原话：「当作第一步 和 第二步 生成文档时 必须遵循的内容准则」「不管是写规则 还是 写文档 都要严格按照说人话的技能去执行」。 + - 适用面两类都算，只改产出不改规则等于半改。一是产出文档：`research/1a-需求文档.md` 到 `1e-使用场景.md`（5 份）、`research/1b-独立分析/`（独立分析体）、`产品规划/prd/2a-产品功能.md` 与 `产品规划/prd/2b-界面布局.md`（2 份）。二是规则本身：本技能包内的一切落盘文字，`SKILL.md`、`references/**`、模板与清单。 + - 判据来源（单一可信源，本文件不复述模式清单）：**只有 `humanizer` 一份，且只用它的英文正式目录** —— `<技能根>/humanizer/references/patterns.md` 的 **P1–P55**（内容 8／语言与风格 10／沟通 3／填充与模糊 9／新兴 13／工艺与取证 12）。另有 5 种口吻档（casual / professional / technical / warm / blunt）。 + - 🔴 **判据一律用英文目录（2026-10-15 用户令）**：中文附录 `patterns.zh.md`（ZH1–ZH15）**只作参考线索，⛔ 不作判据** —— 作者自标「实验性、未经中文母语写手校验、不应被当作已验证的规则」。原中文版 `humanizer-zh` 的 24 条与五维 50 分表随该技能删除一并停用作废。 + - 门槛（2026-10-15 改）： + · **英文产出**：可读 `--score` 的 0–100 AI 痕迹密度分（越低越像人；上游 pre-commit 的拦截线是 40），本包不设硬阈值，分数写进段末报告。 + · **中文产出**：⛔ 不采信自动分数 —— 该打分器按 `[.!?]` 切句、按 `[a-z0-9]` 切词，中文 `。！？` 不切句、汉字零词，分数实际在测「文件里有多少拉丁字符」（实测：同一段中文把 `。` 换成 `. ` 分数不变；零拉丁字符的中文直接判 `No text`）。改按 **P1–P55 逐条人工对照**，再跑 `--check-facts` 保真（它只抽数字／日期／版本／URL／路径／标识符，中文同形可用）。对照结果与事实存活数写进段末报告，命中项不对完不许落盘。 + - ⛔ 取不到判据来源时（2026-10-08 补）：两份技能都不在位或读不到 ⇒ **不许凭感觉判「这条够人话」**。在段末报告与 3d 审查留痕件（`3d-审查报告.md` 或 `DESIGN.md` 审查节）里明写「无判据来源，本项未判」，按与 §供给·工艺数值判据 的「证据缺口」同一口径处理。 + - 五条核心原则（2026-10-15 起**就地固化在本包**；原引自已删除的 `humanizer-zh`《核心规则速查》，英文版 `humanizer` 的 Quick reference 没有等价条目，故不再指向外部）：删填充短语（开场白、强调性拐杖词）；打破公式结构（二元对比、戏剧性分段、修辞性设置）；变化节奏（长短交错，两项优于三项，段尾多样）；信任读者（直接陈述事实，跳过软化、辩解、手把手引导）；删金句（读起来像可引用的话，就重写它）。 + - 🔴 **适用面要划清（2026-10-15 排查后立）**：本包只取这份技能里**「去 AI 味」那一半**，⛔ 不取**「注入个性」那一半**。 + 取这些：英文模式目录 `references/patterns.md` 的 P1–P55、就地固化的五条核心原则、禁用清单。 + 不取这些：`Soul Injection Techniques` 整节（11 条）—— 它明写「有观点、别只报告事实」「用具体感官／体验细节代替抽象说法」「允许跑题与题外话」「结尾不必收束」「用 imperfect start 开场」，与本包产出要的**客观书面说明文**正好相反（照它写会出乱比喻、口水话、不能简明扼要）。该节第 3 条自带的示例就是「凌晨两点冷咖啡和看不懂的堆栈」这种感官化写法。 + 口吻档：本包产出**固定取 `technical`**（精确用词、一句一个意思、⛔ 无比喻除非确能澄清），⛔ 不用 casual／warm／blunt。 + ⛔ **已停用**：原中文版 `humanizer-zh` 及其五维 50 分表（该技能 2026-10-15 已整包删除，判据不再走它）。 + - 🔴 **同一件事更严的那份说了算**：④段的 `references/doc-language-spec.md`（客观书面说明文 ＋ 逐条禁用清单）是本包最严的一份语体规范；任一段落盘文字与它冲突，**以它为准**。 + - 交付留证：产出文档在段末报告里写明「已过内容准则，评分 X/50」；改规则文件时，在当日 memory 里记下这一关过了。 +- 只调一段时不越界：用户说「只做第 N 段」，就跑该段，不展开其他段，也不用「你还没做调研」去催促。 +- 提问上限 3 个：其余用合理假设，并在文档里标注 `【假设】`。例外是 `grill-me` 提问模式，不受此限（①段的「需求澄清」与②段的「需求压测」各一次），该模式的价值就是穷尽提问；此时须先声明「将连续多轮提问」，退出后恢复本约束。 +- 反问优先，允许自动补全：`grill-me` 的默认动作是把问题抛给用户并附推荐答案。用户说「你定」、连续两轮不回应、或属事实类问题时，模型自行给答案并标 `【假设】`，换来「不卡住」；但每轮结束要汇出待复核清单，未经复核的 `【假设】` 不得在下游当事实用。 +- 停线规则（**单一真源，全包只在本节写一次**，各段一律引用、⛔ 不复述）：只有三种情况停 —— ① 信息不足且查不到；② 破坏性／不可逆动作；③ 用户显式要求。 +- MVP 边界优先：任何阶段都先回答「第一版做什么、不做什么」。 +- 必须落盘：产出写入文件，不要只在对话里输出。 +- 无来源就标注：任何查不到来源的数据都标为「估算」并写明口径，不编造数字当事实。 +- 禁止长文：单份产出物默认一页纸（≤120 行），超长必须拆分。 +- ⭐ 落盘产出的排版（2026-10-14 用户令，原话「标题周围写小字的怪毛病 彻底改掉」）：元信息（条数、口径、读法、状态）写进表格的列、条目的字段或表头；标题旁边、标题下面、标题后面都只放标题本身。④段的 `references/doc-language-spec.md` 另有一份更细的，冲突以那份为准。 +- 🔴 路径写相对或占位（2026-10-14 用户令）：本包内一切文字（`SKILL.md`、`references/**`、脚本与注释、模板）引用**本技能自己或同根技能**的位置时，写相对形态 —— 同根技能写 `<技能根>/<技能名>/`，本包自己的文件写包内相对路径（如 `references/stage-delivery/`）。只有**跨根引用**（工作区根、文档库根、本机软件安装位这类从本包推不出来的别的根）才落到具体位置，且优先读环境变量（`DSH_WS_ROOT` / `DSH_DOCS_ROOT` / `WORKBUDDY_BIN_ROOT`）。原因：技能根的位置随环境变（全局技能根还是工作区技能根、用户名与盘符各不相同），写死了换台机器就是死路径，跨环境会整片报错。 + +## 征询外部模型（GPT）的提问口径（单一真源） + +> 🔴 2026-10-15 用户令，逐字：「问 GPT 的时候 只需要说明 关键背景情况和需求询问，禁止带入过多细节上下问造成干扰」。本包内一切向外提问的动作都按本节写；③段 3c 的提问模板是本节的一个实例，⛔ 不在别处另立一套口径。 + +- **要写三样**：① 场景一句（这是什么、要解决什么）；② 手上已有什么（只列与本次提问有关的）；③ 想问哪几个问题（逐条列，一条一个问点，末尾一句收口）。 +- **判据**：背景写到「对方能接住这个问题」为止 —— 少了这句，对方就问不出对的问题吗？问不出才留，问得出就删。 +- **⛔ 不带**：过程留痕、已废弃做法的设计细节、「我们为什么这么做」的来龙去脉、内部硬约束清单、字段与文件清单。这些会把回答拖进细节纠缠，占掉本该用在核心问题上的注意力。 +- **为什么**（避坑依据 · 2026-10-14 实测）：为问「原型说明文档该怎么写」，先铺了 1 500 余字的背景（含已废弃做法的 5 个设计点、4 条硬约束、7 个问题）⇒ 细节量压过问题本身。 +- **留痕**：提问原文与回答原文都要落盘；提问按本节写，⛔ 不把本机路径当内容（外部模型看不到本机路径，要么逐字内联、要么上传文件）。 + +## 产出文档开头必须有图（单一真源） + +> 2026-10-15 用户令，逐字：「产品规划页面 所有文档前面都要画图」。各段一律引用本节，⛔ 不在段内另写一套口径。 + +- 每份落盘文档**第一屏就给一张图**：图放在标题之后、正文之前 —— 不读正文也能先拿到全貌。 +- 图是**正文内容**，⛔ 不写成标题旁边或标题下面的注解小字（与上面那条排版红线同一件事）。 +- 图要**表达结构或流程**（二选一或兼具）—— 一张图看完就知道「由哪几块组成、怎么连起来」或「一件事分几步走」；⛔ 不做纯装饰性配图。 +- 图表达这份文档**覆盖的东西之间的关系**，按段定画什么： + · ①段（`research/` 五份）—— 画对象与流向：为谁解决什么、信息从哪来到哪去。 + · ②段（文档根 `产品规划/prd/` 两份）—— 画页面骨架：有哪几页、每页几个板块、跨页关系怎么走。 + · ③段（`ui/` 下的产物与 `DESIGN.md`）—— 画页面结构与操作动线：用户办成一件事实际经过哪几页、每页做什么、哪里要来回跳。 + · ④段（产品文档）—— 画页面结构图（各页面与其下的功能编号）＋ 用户路径：各场景怎么串起来。 +- 画图用 `diagram-design`，⛔ 不手写 Mermaid（判据见「工具选择规则」那张表）。 +- 图里每格写清名字、线标方向；图与正文互相对得上 —— 正文新增或改了结构，图要跟着改，两处不许各说各的。 + +## 每段的标准收尾格式 + +``` +## 本段结论 +- （3-5 条，可直接决策的话） + +## 已落盘 +- ... + +## 待确认（最多 3 条） + +## 建议下一步 +→ 用 完成 <具体事> +``` + +## 反面清单 + +- 为一个小功能跑完整调研 +- 输出长文却给不出一个结论 +- 跳过「不做什么」 +- 用户只问单点，却强行拉进全链路 +- 把估算数据写成确凿事实 +- 跳过③段 D0 的 Gate-1（未定死令牌表与设计契约）就开写页面代码 +- 在 `grill-me` 提问模式下仍套用「提问上限 3 个」，把提问做成走过场 +- 只跑一次 `grill-me`：①没定义需求就去取证，或②拿①段的需求定义代替功能压测直接写②段 +- 把自动补全当默认动作：用户没说话就替用户拍板，还没标 `【假设】`、没进待复核清单 +- 手写 Mermaid 代替 diagram-design，手写 token 表代替 DESIGN.md +- 绕过四段自己手搓，或重写它们的内容（该调 `stage-*` 就调） +- 把供给件的内部路径按本 skill 目录去拼，或改它们的正文 —— 供给件指③段自带的 `oil-ui-pro`，以及 §供给 各档落在 `assets/` 下的件（它们是随③段携带的供给件，改动只写 `stage-delivery` 自己的 `SKILL.md` / `references/`；默认档与可选档平行，不缝成一条流水线，也不把 `oil-ui-pro` 的评分循环当成本段 Gate 的替代） +- 猜 `<项目>`：定不出来还硬写，把产物落到别的项目目录下 +- 把 `DESIGN.md` 写到仓库根：多项目会互相覆盖 +- 段间停下来问「要不要继续」：全流程（自动处理）模式下直接进下一段，只在段末输出报告 +- 把两种模式混用：在自动处理模式下自作主张停下问方案，或在「方案确认」模式下确认前就开跑②③④ +- 在「方案确认」模式下把①段的方案当成已确认就往下跑：该模式下①段末必须停下等用户确认（含「不做什么」） +- 下游擅自裁剪上游已拍板项：②③④发现要砍①段或决策表里已拍板的东西时，不许自行裁掉或改口径，必须列成「与已定决策的差异」交用户显式确认 +- 把模式当成段：模式是「要不要在①段末停」的开关，不是第五个段，别为它单独造段或造产物 +- 跑了却不说：没声明当前段 / 子步与依据文件，或偏离了被调 skill 的主流程却不声明、不记偏离单（应为：开工先声明、每个子步再声明、偏离当场声明） +- 让③段顺手把说明区或产品文档写了（那是第④段 `stage-proto-doc` 的活） +- ④段里重新规划产品、重新设计界面，或写原型上没有的页面 / 功能 / 业务规则（④段只解释与记录**现有**原型） +- 问外部模型时堆砌背景：把过程留痕、废弃做法、内部约束清单整段贴进去（应按「征询外部模型（GPT）的提问口径」只给关键背景 ＋ 明确问题） +- 落盘文档开头不给图，或图与正文各说各的（应按「产出文档开头必须有图」先上图、再写正文，两处对得上） +- 过「说人话」时把「注入个性」那半也照做：加观点、加第一人称、写感官细节与比喻、允许跑题（应按内容准则只取「去 AI 味」那半，产出仍是客观书面说明文） + +## 改名 / 改供给后的自检 + +```bash +python scripts/check_naming.py --ws <工作区或产品根> +python scripts/selftest_product_root.py +``` + +`check_naming.py` 查四段段名与子步名在「总入口 ↔ 各段 `SKILL.md` ↔ 各段 `references/`」之间有没有漂，包括 H1 与子步表是否一致、总入口子步列有没有漏项、runbook 必读表有没有引用已移除的资产、两份副本是否一致；顺带按 `--ws` 认出的**产品根**扫 ①②段产出白名单。纯静态比对，不需要渲染，不需要外部依赖。 + +`selftest_product_root.py` 只验一件事：**产品根认得对不对**（造临时夹具，⛔ 不碰真实工作区）。三条路都要成立：单产品时给工作区根 / 给产品根本身 / 从子目录向上都认得出同一层；多产品又没有 `.registry/current-project` 指针时**返回空**（⛔ 不猜、不随手拿第一个，让模型停下来问用户）。认错产品根会把产物写进别的产品目录，事后极难拆干净，所以这条单独立测。 + +为什么必须有它：实测当天漏过两次，当时没有任何门禁会报错。 + +第一次（2026-10-02）：改段名时 `SKILL.md` 改了，但 `references/stage-discovery/references/grill-me.md` 的 H1 仍写「需求澄清（grill-me · 调研段）」；`references/stage-requirements/SKILL.md` 子步表写「2b 功能流转」而正文 H2 写「## 2b 状态机」；总入口④段子步列只写「4a 说明区 / 演示引导」漏了 4b / 4c。三处都只能靠回读发现。 + +第二次（2026-10-06）：②段收窄为「只细化功能」（7 份产出变 1 份）后，各段 `SKILL.md` 都改了，但总入口的三处仍写着旧结构——四段表的②段子步列仍是「2a 功能定义与压测 / 2b 功能流转 / 2c 功能图示」，四段表的①段子步列「1c 产品定位与商业设计」未随段内改名（段内已改称「产品定位与场景」），正文仍写「①与②各跑一次 `grill-me`」并指向两份同名文档，实际全场只有①段一份。闸门当场报 6 个 FAIL，根因是「改了承载段、忘了总入口」。 + +由此立一条硬纪律，与「换供给不能只改承载段」同型：凡改子步结构 / 段内产出清单 / 段间交接口，必须连带改总入口 `product-planning/SKILL.md` 的「四段结构」表与「交接口」表，不改就是半改状态。 + +改了段名 / 子步名 / 判据供给源之后必须跑一次，并把结果记进当日 memory。改完不校验，下次读契约的人拿到的是错的配方。 + +本脚本只查文本一致性（H1 ↔ 子步表 ↔ 总入口 ↔ 副本），查不出「判据口径是否自相矛盾」。例如「②段到底该不该给页面结构」这种反转，闸门一个字都报不出来。口径类改动要靠人工回读，且必须把反转理由与用户原话写进文档留痕。 + +脚本输出里的 `[提示]` 项（旧名出现）不计入失败，但要人工看一眼是不是落在「废止理由块」里——落在里面是正当留痕，散落在正文里就是真残留。 + +2026-10-07 起本技能只在全局一份：技能根下的 `product-planning/`。它就是本体，不再有「主 / 副 / 装入」三副本，也不再需要「三处 md5 复核」（那只在有副本时才有意义）。改完只跑一次 `check_naming.py --ws <工作区>`。用户原话：「把产品规划复制到 workbuddy 全局skills中 后续维护和使用全局技能」。工作区原先那三份已归档到 `归档/技能迁全局-20261007/`（未直删，可随时取回）。 diff --git a/product-planning/references/_留痕/SKILL-总入口-20261016改element-picker落点前.md b/product-planning/references/_留痕/SKILL-总入口-20261016改element-picker落点前.md new file mode 100644 index 0000000..516ecb5 --- /dev/null +++ b/product-planning/references/_留痕/SKILL-总入口-20261016改element-picker落点前.md @@ -0,0 +1,322 @@ +--- +name: product-planning +description: 产品规划总入口（唯一入口），四段式调度：① 产品需求 ② 产品功能 ③ 界面交互 ④ 原型说明文档。四段以 references/stage-* 承载，本文件是总调度与约束。可整段跑也可只调一段。当用户要做产品规划、从零做新产品、只做某一阶段、或不知道从哪开始时调用。 +--- + +# 产品规划总入口 + +> 本 skill 由模型按需自动加载，没有斜杠命令。对话里还没定出对象时，先按「项目与路径约定」定出 `<项目>`；定不出来就停下问用户，不要自行假设。 + +## 用途 + +用户丢来一句模糊想法（例如「我要做一个 AI 短剧分镜画布」）时，本 skill 判断该走哪一段，只做那一段的最小必要工作，产出可交付物，再推进到下一段。 + +本文件管调度与约束。各段怎么做，写在 `references/stage-*` 各自的文件里。 + +## 四段结构（可整段跑，也可只调一段） + +| 段 | 回答的问题 | 子步 | 调用 | 产出物 | +|---|---|---|---|---| +| **① 产品需求** | 要做的东西凭什么成立：什么问题、为谁、为什么值得做 | 1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景 | `stage-discovery` | `产品规划/research/*`。其中 1b 交两种体例：`research/1b-竞品分析.md`（汇总对比）＋ `research/1b-独立分析/<竞品名>.md`（独立分析） | +| **② 产品功能** | 要做哪些功能、什么不做、长成什么骨架 | 2a 产品功能 / 2b 界面布局 | `stage-requirements` | `产品规划/prd/2a-产品功能.md` 与 `产品规划/prd/2b-界面布局.md`（两份） | +| **③ 界面交互** | 长什么样、怎么操作 | 3a 视觉规范 / 3b 原型 / 3c GPT参考版 / 3d 审查打磨 | `stage-delivery` | `产品原型/designs/DESIGN.md`、`产品原型/pages/*.html`、`产品原型/designs/3c-GPT参考版.md` | +| **④ 原型说明文档** | 现有原型怎么用、每条功能落在哪个页面、坏了怎样、怎么核对（文档按七节铺：原型地址 → 页面结构 → 功能清单 → 使用场景 → 操作流程 → 页面导航 → 原型状态取值） | 4a 场景盘点 / 4b 说明区 / 4c 演示引导（可选） | `stage-proto-doc` | 原型内嵌说明区 ＋ 独立产品文档 `产品原型/pages/<产品项目名>.html`（两份共用同一套 P 页面／S 场景／F 功能／J 二级功能编号） | + +四段只通过落盘文件耦合。段间交接口如下，这是唯一的契约，越界即失效： + +| 交接 | 由谁给 | 给什么 | 给到哪为止 | +|---|---|---|---| +| ① → ② | ① | 问题定义、需求澄清决策表（含 grill 压测的 B 节：做成什么样 / 哪些情况不成立 / 状态怎么流转）、取证结论（1b 汇总对比体 ＋ 1b 独立分析体、1c 用户画像）、产品定位、《使用场景》＝用户故事（②段功能的直接推导依据） | 功能清单归②段产出，1a 写到需求与形态为止 | +| ② → ③ | ② | 功能清单（每条带优先级 ＋ 状态流转）、界面布局（有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系）、每页主操作、信息承载分档（主屏常驻 / 可点入） | 视觉归③段。骨架必须给全，骨架不给全，③段就一版一个样 | +| ③ → ④ | ③ | 已跑通的单文件原型 HTML（页面、模块、控件、状态、交互、跳转、反馈＝界面事实的唯一依据） | 说明区与独立产品文档归④段；⛔ ④段不重新规划产品、不重新设计界面 | + +> 口径：②段钉骨架，③段做皮肉。两侧逐行对照与用户原话只在②段 `references/stage-requirements/SKILL.md` 的 §②—③ 交接口 定义一次 —— 本入口不复述。要点两条：②段要给全「归②段」列；③段不许增删移动板块，缺板块回②段改。 + +> ②→③ 最容易搞坏。旧病灶：②段说「必须能读到」，③段读成「必须常驻主屏」，五类信息就全铺一屏成了信息墙。分档表把「读到」明确成「一次点击内可达」，防的就是这句歧义。骨架是灰块（有哪些块、什么顺序），③段给的是视觉与交互实现（排版、点哪有什么反馈、空态、响应式）。两件事各管一维，③段不会退化成照抄。 + +> 四段各占一个词，互不共用（2026-10-02 定）：产品 / 功能 / 界面 / 说明。改段名前先对照这张表；两个段名里出现同一个词，边界一定在漂。旧名「调研与方案 / 需求与结构」都含「需求」，③段旧名里的「交付」是三段共有的属性，都属名实不符，已改。 +> 🔴 **④段的沿革（2026-10-14 → 10-15）**：10-14 按用户令删掉**旧版**④段 —— 旧做法是往原型 HTML 注入说明区注解层（状态 → 场景 → 从左到右流程图 → 功能作用/输入边界/异常情况 三段 → 逐步骤演示引导），实测没法用，整段连方法论一并撤掉。10-15 用备份里的**新版**④段装上：改成「解释与记录现有原型」，交**两份产物**（原型内嵌说明区 ＋ 独立产品文档 `产品原型/pages/<产品项目名>.html`），内容先按四块＋附录铺，随后整套同步成**七节**（原型地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值），编号改用 P 页面／S 场景／F 功能／J 二级功能，并带一份现成模板 `references/stage-proto-doc/assets/产品文档模板.html`。判据正文在 `references/stage-proto-doc/`，⛔ 旧版那套（状态轴、三段必填、逐步骤演示）不再使用。 +> ①叫「产品需求」不叫「需求调研」：该段产出 `research/1a-需求文档.md`、`1b-竞品分析.md`、`1c-用户画像.md`，也产出 `1d-产品策略.md`、`1e-使用场景.md`，「调研」二字盖不住后半截。 +> ⭐ 1b 是①段唯一交两种体例的子步：独立分析体 `research/1b-独立分析/<竞品名>.md`（竞品池每一个一份），汇总对比体 `research/1b-竞品分析.md`（恒一份）。职责边界与定案原话见 `references/stage-discovery/references/competitor-analysis.md` §0.4。 + +⭐ `grill-me` 全场只有①段一份（2026-10-06 用户定案）：①段那份按 A / B 两节提问，火力点划分、节次归属与定案原话见 `references/stage-discovery/references/grill-me.md` —— ⛔ 本入口不复述。B 节结论落进 `research/1a-需求文档.md`。 + +⭐ ②段产出两份（2026-10-06 收窄，2026-10-07 定为两份）：`产品规划/prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 ＋ 状态流转）与 `产品规划/prd/2b-界面布局.md`（页面关系 ＋ 页面内板块布局）。定案原话与理由见 `references/stage-requirements/SKILL.md` 开头。 + +（交接口反转前的口径、②段收窄前的产出清单与去向 → `references/_留痕/③段与总入口-旧口径.md`） + +⚠️ ①段功能按「使用场景」组织（一条场景可跨多个页面），不按页面组织。 + +段内的子步顺序、方法论文档、硬约束、完成标准，都在各段自己的 `SKILL.md` 与 `references/` 里。 + +①段 1a 需求文档：全程最先做，且只做一次。用 grill-me 与用户互动，产出 `产品规划/research/1a-需求文档.md`（开头写清做什么 / 为谁 / 不做什么，往下是决策表）。 + +## 项目与路径约定（单一真源） + +> 四段全部遵守本节。**产品根** ＝ 同时含 `产品规划/` 与 `产品原型/` 的那一层目录（例 `<工作区>/项目/script-shortvideo/`）。各段 `SKILL.md` 与 `references/` 里的 `产品规划/...`、`产品原型/...` 一律**相对产品根**读。 + +### 目录长什么样 + +工作区顶层只放 `项目/`｜`调研/`｜`复盘/`（外加机制自己的 `tmp/`、`交付物/`、`执行会话/`、`.workbuddy/`、`.registry/`）。 + +`项目/` 下是**产品文件夹**，一个产品一层，目录名就是产品 slug（小写字母、数字、连字符，例 `my-tool`、`script-shortvideo`）—— 这个目录就是**产品根**。产品根下三个落点： + +| 根 | 路径 | 装什么 | +|---|---|---| +| 🔴 **文档根** | `产品规划/` | ①段 `research/`（`1a`~`1e`）、②段 `prd/`（`2a-产品功能.md` ／ `2b-界面布局.md`）、跨段 `专题/` | +| 🔴 **设计根** | `产品原型/designs/` | ③段 `DESIGN.md` ＋ `3c-GPT参考版.md` ＋ 3d 审查留痕件 ＋ 截图 `_gate_shots/` | +| 🔴 **页面根** | `产品原型/pages/` | ③段原型 `*.html` ＋ ④段独立产品文档 `<产品项目名>.html` ＋ 页面用静态资源 | + +⚠️ **②段 prd 归文档根**，⛔ 不跟③段一起搬 —— 它与①段 `research/` 同根，③段的机检脚本也按 `产品规划/prd/2b-*.md` 去定位它（`find_doc`）。⛔ 已废的那层 `ui/` 子目录不要再写进任何判据。 +⚠️ **原型页面不放在设计根**（放在页面根 `产品原型/pages/`）：③段的机检脚本按 `产品原型/pages/*.html` 找原型（`find_proto`）。⛔ 原型 HTML 一律落页面根，设计根只留规范与参考件。 + +### slug 怎么定（按序取第一个成立的） + +| 序 | 条件 | 取值 | +|---|---|---| +| 1 | 用户在当前会话里明确说了项目名 | 该名字 slug 化 | +| 2 | `.registry/current-project` 存在且非空 | 其内容 | +| 3 | `项目/` 下恰有一个非 `_` 开头的目录 | 该目录名（＝产品根名） | +| 4 | 以上都不成立 | 停下问用户 | + +写任何文件之前先核对：目标路径里产品根那一段的目录名与按上表得出的 slug 是否一致。不一致就停下说明，不要「先写了再说」——猜错会把产物写进别的项目，事后极难拆干净。 + +### 产物落哪 + +| 段 | 路径 | +|---|---| +| ① 产品需求 | `产品规划/research/` | +| ② | `产品规划/prd/` | +| ③ | `产品原型/designs/DESIGN.md`、`产品原型/pages/*.html`、`产品原型/designs/3c-GPT参考版.md` | +| ④ | 原型内嵌说明区（写进 `产品原型/pages/*.html` 自身）＋ 独立产品文档 `产品原型/pages/<产品项目名>.html` | + +### 文档的两态：当前版与过期版 + +用户令（2026-10-11 逐字）：「**应该有文件夹 专门归档过期文档， 当前文档 统一放在方案文件夹中**」。 + +🔴 **方案文件夹** ＝ `产品规划/` 这一层 —— 它下面放的全是**当前权威版**：①段 `research/`、②段 `prd/`、跨段 `专题/`，另加一份 `索引-当前权威版.md` 当入口。 + ⚠️ ③段与④段的产物**不在**文档根 —— 规范类在设计根 `产品原型/designs/`、页面类在页面根 `产品原型/pages/`（见上「产物落哪」）。⛔ 别按老口径去文档根下的 `ui/` 子目录找原型（那层已废）。 +🔴 **归档文件夹** ＝ `产品规划/归档-过期版/` —— 被顶替下来的旧版全放这里，命名 `<原名>__<来源目标短哈希>.<扩展名>`（例 `2b-界面布局-新版__fc471a.md`）。 +🔴 **设计根与页面根也各有归档文件夹** ＝ `产品原型/designs/归档-过期版/` 与 `产品原型/pages/归档-过期版/` —— 前者收被替换下来的设计规范与参考件，后者收被替换下来的原型页面与历史产品文档；命名带版本号或日期以便分辨。 + +**每个目标收口时做四步**： +1、本目标的权威文档**覆盖**方案文件夹里对应的那一份。 +2、被顶替的旧版**移进** `归档-过期版/`，按上面的命名补上来源短哈希。 +3、更新 `索引-当前权威版.md` 里对应行的大小与日期。 +4、执行区（`执行会话/目标-*/` 这类过程目录）里的原件**保留** —— 它既是过程留痕，也是台账 `artifact` 指向的地方，搬空会让回查断链。 + +**为什么要有这条**（避坑依据 · 2026-10-11 实测）：同一个 `2a-产品功能` 在 6 个目标目录里各有版本、`2b` 有 7 个，光看文件名与字节数分不出谁新；而 `产品规划/` 下早先那次归档又停在旧版（`2b` 只 52 256 B，最新已是 52 643 B）⇒ 用户问「很多新老方案都在文件夹中，后续根据方案细化产品界面，如何找得到对应的方案」。判断某份文档的当前版，**只看方案文件夹**；问「当时为什么这么定」才去归档文件夹翻。 + +### DESIGN.md 为什么在产品根、不在工作区根 + +`DESIGN.md` 是③段的绑定视觉规范，一个产品一份，③段按产品 slug 去读它。工作区根只能放一份，多产品会互相覆盖，所以一律放 `产品原型/designs/DESIGN.md`。 + +推论（硬规则）：读 `DESIGN.md` 时，路径必须由本节定义的**产品根**拼出，不许用「当前工作目录碰巧有 DESIGN.md」这类推断。工作区根不放任何产品的 `DESIGN.md`。 + +## 工具选择规则（防止选错，最重要的一节） + +> 下表是选型总则。这些工具都已封装在对应段内，本文件只负责让你不选错；具体调用路径见各段 `SKILL.md`。 + +| 要什么 | 用谁 | 别用 | +|---|---|---| +| 页面设计全链（规范 → 原型 → 审查） | ③段 `stage-delivery` 自己的 D0→D5 流水线 | 另找风格库，或自己手搓一套 token 与门禁 | +| 评审用的可点原型 / 生产级前端页面 | ③段 3b（按 D2 构建，单文件 HTML 交付）。先判页型：营销页取③段 §供给·版式骨架 的可选档，工具型页面取其默认档 | 不判页型就套可选档种子——那是营销落地页骨架，会把后台做成营销页 | +| 设计规范文件 | ③段 3a 生成 `DESIGN.md`（令牌表取自③段选定套，见③段 §供给·定调与令牌；再加该项目②段的界面需求） | 凭空编一套 token | +| 架构图 / 流程图 / 时序图 | `diagram-design` | 手写 Mermaid | +| 状态迁移的守卫、副作用、并发 | `state-machine` | 指望 diagram-design 覆盖这些 | +| 审美方向 / 风格定调 | ③段 §供给·定调与令牌 的默认档里选一套（可选档亦见该处），读候选套按页面类型挑。⛔ 每次只选一套 | 「米白＋衬线＋陶土色」这类默认审美，或凭感觉编 | +| 多方向比选 / 独立评审打分 | ③段 §供给·多方向比选 与 §供给·独立评审协议 | 拿它的评分循环替代本段 Gate-1/2/3 | + +③段的页面设计供给 —— 默认主线、定调与令牌、版式骨架、工艺数值判据、独立评审协议、多方向比选，共六档；各档的默认来源 / 可选来源 / 路径只在③段 `references/stage-delivery/SKILL.md` 的 §供给 定义一次，本入口不复述，要改供给只改那一块（2026-10-08 起）。`oil-ui-pro` 是界面设计方法论：五步流程（探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付），加风格对比页与截图工具；它自带联网版本检查与自动更新，是用户明确要求全量搬入的例外项（既有纪律是「依赖外部服务一律不收」），已记录在案，不扩散。 + +默认走 `oil-ui-pro` 主线，不与可选档缝成一条流水线：可选档只在 §供给 里列，选了才作补强（多一路定调候选、多一套工艺数值判据），不选也不影响开工。 + +四样东西供给件里都没有对应，由 `stage-delivery` 自己扛：设计契约十二字段、结构骨架、交互清单、工具型版式库。 + +页型分流（2026-10-05 新增）：③段 §供给·版式骨架 的可选档是营销落地页向，工具型页面照它做会长出「标题上下各一行小字」的三段式（骨架名单与理由见③段 `references/stage-delivery/references/layouts-tooling.md` 开头）。本项目实测踩过这个坑，结构判据全绿也拦不住。所以③段 D0 必须先判页型，工具型页面版式一律走 §供给·版式骨架 的默认档。 + +只读一处来源：同一条判据若在默认档与可选档各有一份且口径不同，以本项目追加条为准 —— ⛔ 但追加条不得放宽基础层（`oil-ui-pro` 是基础层、其余是叠加层，分层规则见③段 §供给），并在 runbook §3.4 显式标注「本项目追加」。 + +DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec` 四个子命令，目前是 alpha（v0.4.0）。非 TTY 的管道里可能不回显输出，需在真实终端里确认。本机实测该命令完全不可用，不要拿它当校验关卡；改由 D3 收口与 D5 终检按真实像素人工复测对比度（判据见③段 §供给·工艺数值判据 里配色那一份）。原两把门禁脚本（静态文案检查 / 渲染机检）已随旧主干从磁盘移除，当前没有机器复现，结论只能记「人工判定」，不得写成「脚本已通过」。 + +## 可调用工具（自然语言触发） + +> 三个独立工具，按用户说法直接触发，产物落项目目录。`design-capture` 随③段携带（装在③段 `references/stage-delivery/assets/` 下）；`video-capture` 2026-10-11、`element-picker` 2026-10-16 先后独立成全局技能（都装在**技能根**下），跨段跨项目复用。三者都不单独成段。 + +| 用户说 | 触发工具 | 做什么 | 产物 | +|---|---|---|---| +| 「分析 XXX 视频」「把这个视频抽帧」「拆一下这条视频的画面」 | 全局技能 `video-capture` | 取视频（本地文件 / 直链 URL / 平台页经浏览器下到本地）＋ 抽帧（双因素 ＋ 首尾 ＋ 补帧） | 关键帧 `c_<序号>_<真实秒数>s.jpg` ＋ `frame_times.json`（供①竞品分析、③视觉参考） | +| 「获取 XXX 网站的设计风格」「抓这个网站的风格/组件/配色」 | `stage-delivery/assets/design-capture/` | 抓网页设计系统（色彩 / 排版 / 组件），生成样式模板 | 一套 `design-system-<名>/`（与 `design-system-tiaoyue` 同构，可直接被③段 D1 选用） | +| 「选中这个组件」「把这个元素的位置给你」「改这个页面的样式」「这个按钮在哪」 | 全局技能 `element-picker` | 在浏览器里点选任意组件，取出它的 CSS 选择器与所属网页，交给 AI 定位源码改样式 | 剪贴板两行（`选择器：…` / `网页：…`）＋ 存档 `marks/_ui-marks.json`（含文本 / class / 属性 / 尺寸 / 关键样式 / HTML 片段） | + +三者都独立可单跑：`video-capture` 只依赖 `ffmpeg`（权威件＝全局技能 `video-capture`；原 `stage-delivery/assets/video-capture/` 只留交接说明，脚本迁至 `references/_留痕/video-capture-已独立-20261011/` 留档）；`design-capture` 只依赖本机 Chrome（CDP）＋ `vendor/` 里搬运的抽取脚本，不需要任何外部服务在场；`element-picker` 只依赖 Node 标准库起一个本地服务（默认 8890，扩展那一路装一次即对所有网页可用）。用法与边界见各自 `SKILL.md`，来源与署名见各自 `ATTRIBUTION.md`。 + +触发时机：①②段拆竞品视频用全局技能 `video-capture`；③段要新建样式或拆参考站用 `design-capture`；③段以及任何"用户指着一个组件说改这里"的场合用 `element-picker`。 + +两个抓取类工具（`video-capture`、`design-capture`）都只做合规最小集：不抓平台页内视频，不调付费接口；抽取结果须先目视比对再采用。`element-picker` 不抓取任何数据，只读当前页面自身的 DOM、把结果落在本地文件。 + +## 进入方式 + +| 你说什么 | 模式 | 从哪开始 | +|---|---|---| +| 「规划 XX」「从零做 XX」 | 全流程（自动处理） | `stage-discovery` → `stage-requirements` → `stage-delivery` → `stage-proto-doc`，一路跑完，段间不停下来问（含①段末） | +| 「先确认方案」「跑完方案停下等我」「规划 XX，先给方案」 | 方案确认 | 同一套四段，唯一差别是①段末停下等你确认方案，确认后才进②③④ | +| 「只做产品需求」「只做产品功能」「只做界面交互」「只做原型说明文档」 | 单段 | 只调对应那一个 stage skill，不展开其他段 | +| 已有②段，要出原型 | 单段 | 直接调 `stage-delivery`，从它的 3a 起 | +| 已有原型，要补说明 | 单段 | 直接调 `stage-proto-doc`，从它的 4a 起 | +| 只问某个单点 | 单段 | 不跑任何段，在对应 stage skill 内点名子步，或直接说要看哪份方法论 | + +「只调一段」成立的原因：四段之间只通过落盘文件耦合，没有隐式状态。 + +- ②只读 `产品规划/research/*`；缺失时标注 `【假设】`继续，不催促回补① +- ③只读 `产品规划/prd/*`；缺失时同样标 `【假设】`继续 +- ④只读 `产品原型/pages/*.html`（界面事实的唯一依据），另按需读 `产品规划/prd/*` 与 `research/1a-需求文档.md` 定业务意图；缺失时标 `【假设】`继续，并在段末偏离单里写明 + +## 执行规则 + +只有三种模式，没有第四种： + +| 模式 | 段之间 | 段之内 | +|---|---|---| +| 全流程（自动处理） | 一路跑完，段间不停下来问（含①段末）。每段结束按「标准收尾格式」输出一段报告，输出完即刻进下一段 | 子步之间不反问，做完直接进下一个子步 | +| 方案确认 | 与全流程完全相同，只有一处不同：①段末停下等你确认方案；确认后②③④一路跑完、段间不停 | 同上 | +| 单段 | 不涉及 | 不越界，不催促回补前段 | + +这两条是全流程模式下的两个独立分支，不要混：全流程（自动处理）没有①段末的强制停；「停下等确认方案」只在「方案确认」模式下发生。二选一由用户定（界面里点【生成原型和文档】时选「自动处理」或「先确认方案」，或在会话里直接说明）；用户没明说时按自动处理走，不要在自动处理模式下自作主张停下来问。 + +「停下」指什么，不要读成「每一步都要反问用户」。只有这四种情况才停： + +1. 信息不足且查不到，必须用户给（如「项目与路径约定」slug 第 4 条）——停下问 +2. 破坏性 / 不可逆动作——二次确认 +3. 用户显式要求某个子步做完停下 +4. ①段末的方案确认（仅「方案确认」模式）——把方案摆给用户：做什么 / 不做什么 / MVP 边界 / 未复核的 `【假设】`，明说「等你确认方案，确认前不进②段」 + +段末报告：全流程（自动处理）模式下，所有段（含①）都只输出报告，不提问、不等回答；方案确认模式下①段是唯一例外，其余段同样只输出报告。 + +①段末的确认是回环，不是一次问答（仅「方案确认」模式）：用户看到方案后可以提问题要求改，可能多轮，每轮的「问题＋怎么改的」都要留痕、不得覆盖上一轮；改完由用户显式说「确认方案」才算过闸门。该模式下，没拿到用户确认的方案不得当成既定事实带进②段——这是实测踩过的坑：②段拿着未经确认的方案往下跑，把用户已拍板的需求裁掉了。 + +其余规则： + +- 声明制（全段适用，不止③段）：开工前、每进一个子段或子步、每处偏离，都要声明三件事——当前在哪、依据哪个文件的哪一节、产出落哪；偏离当场写明原因与影响，段末附偏离单。不许静默偏离。实测踩过的坑：③段 3b 交付了原型却没走当时声明的主流程、没读依据文件，也没当场说，用户追问「基于哪个 skill」才知道。 +- 不做八股：不介绍方法论来源，不列人名，不复述框架历史，直接给结论。 +- ⭐ 内容准则：一切落盘文字都要先过「说人话」这一关（2026-10-07 用户定案，同日扩大到规则文件）。用户原话：「当作第一步 和 第二步 生成文档时 必须遵循的内容准则」「不管是写规则 还是 写文档 都要严格按照说人话的技能去执行」。 + - 适用面两类都算，只改产出不改规则等于半改。一是产出文档：`research/1a-需求文档.md` 到 `1e-使用场景.md`（5 份）、`research/1b-独立分析/`（独立分析体）、`产品规划/prd/2a-产品功能.md` 与 `产品规划/prd/2b-界面布局.md`（2 份）。二是规则本身：本技能包内的一切落盘文字，`SKILL.md`、`references/**`、模板与清单。 + - 判据来源（单一可信源，本文件不复述模式清单）：**只有 `humanizer` 一份，且只用它的英文正式目录** —— `<技能根>/humanizer/references/patterns.md` 的 **P1–P55**（内容 8／语言与风格 10／沟通 3／填充与模糊 9／新兴 13／工艺与取证 12）。另有 5 种口吻档（casual / professional / technical / warm / blunt）。 + - 🔴 **判据一律用英文目录（2026-10-15 用户令）**：中文附录 `patterns.zh.md`（ZH1–ZH15）**只作参考线索，⛔ 不作判据** —— 作者自标「实验性、未经中文母语写手校验、不应被当作已验证的规则」。原中文版 `humanizer-zh` 的 24 条与五维 50 分表随该技能删除一并停用作废。 + - 门槛（2026-10-15 改）： + · **英文产出**：可读 `--score` 的 0–100 AI 痕迹密度分（越低越像人；上游 pre-commit 的拦截线是 40），本包不设硬阈值，分数写进段末报告。 + · **中文产出**：⛔ 不采信自动分数 —— 该打分器按 `[.!?]` 切句、按 `[a-z0-9]` 切词，中文 `。！？` 不切句、汉字零词，分数实际在测「文件里有多少拉丁字符」（实测：同一段中文把 `。` 换成 `. ` 分数不变；零拉丁字符的中文直接判 `No text`）。改按 **P1–P55 逐条人工对照**，再跑 `--check-facts` 保真（它只抽数字／日期／版本／URL／路径／标识符，中文同形可用）。对照结果与事实存活数写进段末报告，命中项不对完不许落盘。 + - ⛔ 取不到判据来源时（2026-10-08 补）：两份技能都不在位或读不到 ⇒ **不许凭感觉判「这条够人话」**。在段末报告与 3d 审查留痕件（`3d-审查报告.md` 或 `DESIGN.md` 审查节）里明写「无判据来源，本项未判」，按与 §供给·工艺数值判据 的「证据缺口」同一口径处理。 + - 五条核心原则（2026-10-15 起**就地固化在本包**；原引自已删除的 `humanizer-zh`《核心规则速查》，英文版 `humanizer` 的 Quick reference 没有等价条目，故不再指向外部）：删填充短语（开场白、强调性拐杖词）；打破公式结构（二元对比、戏剧性分段、修辞性设置）；变化节奏（长短交错，两项优于三项，段尾多样）；信任读者（直接陈述事实，跳过软化、辩解、手把手引导）；删金句（读起来像可引用的话，就重写它）。 + - 🔴 **适用面要划清（2026-10-15 排查后立）**：本包只取这份技能里**「去 AI 味」那一半**，⛔ 不取**「注入个性」那一半**。 + 取这些：英文模式目录 `references/patterns.md` 的 P1–P55、就地固化的五条核心原则、禁用清单。 + 不取这些：`Soul Injection Techniques` 整节（11 条）—— 它明写「有观点、别只报告事实」「用具体感官／体验细节代替抽象说法」「允许跑题与题外话」「结尾不必收束」「用 imperfect start 开场」，与本包产出要的**客观书面说明文**正好相反（照它写会出乱比喻、口水话、不能简明扼要）。该节第 3 条自带的示例就是「凌晨两点冷咖啡和看不懂的堆栈」这种感官化写法。 + 口吻档：本包产出**固定取 `technical`**（精确用词、一句一个意思、⛔ 无比喻除非确能澄清），⛔ 不用 casual／warm／blunt。 + ⛔ **已停用**：原中文版 `humanizer-zh` 及其五维 50 分表（该技能 2026-10-15 已整包删除，判据不再走它）。 + - 🔴 **同一件事更严的那份说了算**：④段的 `references/doc-language-spec.md`（客观书面说明文 ＋ 逐条禁用清单）是本包最严的一份语体规范；任一段落盘文字与它冲突，**以它为准**。 + - 交付留证：产出文档在段末报告里写明「已过内容准则，评分 X/50」；改规则文件时，在当日 memory 里记下这一关过了。 +- 只调一段时不越界：用户说「只做第 N 段」，就跑该段，不展开其他段，也不用「你还没做调研」去催促。 +- 提问上限 3 个：其余用合理假设，并在文档里标注 `【假设】`。例外是 `grill-me` 提问模式，不受此限（①段的「需求澄清」与②段的「需求压测」各一次），该模式的价值就是穷尽提问；此时须先声明「将连续多轮提问」，退出后恢复本约束。 +- 反问优先，允许自动补全：`grill-me` 的默认动作是把问题抛给用户并附推荐答案。用户说「你定」、连续两轮不回应、或属事实类问题时，模型自行给答案并标 `【假设】`，换来「不卡住」；但每轮结束要汇出待复核清单，未经复核的 `【假设】` 不得在下游当事实用。 +- 停线规则（**单一真源，全包只在本节写一次**，各段一律引用、⛔ 不复述）：只有三种情况停 —— ① 信息不足且查不到；② 破坏性／不可逆动作；③ 用户显式要求。 +- MVP 边界优先：任何阶段都先回答「第一版做什么、不做什么」。 +- 必须落盘：产出写入文件，不要只在对话里输出。 +- 无来源就标注：任何查不到来源的数据都标为「估算」并写明口径，不编造数字当事实。 +- 禁止长文：单份产出物默认一页纸（≤120 行），超长必须拆分。 +- ⭐ 落盘产出的排版（2026-10-14 用户令，原话「标题周围写小字的怪毛病 彻底改掉」）：元信息（条数、口径、读法、状态）写进表格的列、条目的字段或表头；标题旁边、标题下面、标题后面都只放标题本身。④段的 `references/doc-language-spec.md` 另有一份更细的，冲突以那份为准。 +- 🔴 路径写相对或占位（2026-10-14 用户令）：本包内一切文字（`SKILL.md`、`references/**`、脚本与注释、模板）引用**本技能自己或同根技能**的位置时，写相对形态 —— 同根技能写 `<技能根>/<技能名>/`，本包自己的文件写包内相对路径（如 `references/stage-delivery/`）。只有**跨根引用**（工作区根、文档库根、本机软件安装位这类从本包推不出来的别的根）才落到具体位置，且优先读环境变量（`DSH_WS_ROOT` / `DSH_DOCS_ROOT` / `WORKBUDDY_BIN_ROOT`）。原因：技能根的位置随环境变（全局技能根还是工作区技能根、用户名与盘符各不相同），写死了换台机器就是死路径，跨环境会整片报错。 + +## 征询外部模型（GPT）的提问口径（单一真源） + +> 🔴 2026-10-15 用户令，逐字：「问 GPT 的时候 只需要说明 关键背景情况和需求询问，禁止带入过多细节上下问造成干扰」。本包内一切向外提问的动作都按本节写；③段 3c 的提问模板是本节的一个实例，⛔ 不在别处另立一套口径。 + +- **要写三样**：① 场景一句（这是什么、要解决什么）；② 手上已有什么（只列与本次提问有关的）；③ 想问哪几个问题（逐条列，一条一个问点，末尾一句收口）。 +- **判据**：背景写到「对方能接住这个问题」为止 —— 少了这句，对方就问不出对的问题吗？问不出才留，问得出就删。 +- **⛔ 不带**：过程留痕、已废弃做法的设计细节、「我们为什么这么做」的来龙去脉、内部硬约束清单、字段与文件清单。这些会把回答拖进细节纠缠，占掉本该用在核心问题上的注意力。 +- **为什么**（避坑依据 · 2026-10-14 实测）：为问「原型说明文档该怎么写」，先铺了 1 500 余字的背景（含已废弃做法的 5 个设计点、4 条硬约束、7 个问题）⇒ 细节量压过问题本身。 +- **留痕**：提问原文与回答原文都要落盘；提问按本节写，⛔ 不把本机路径当内容（外部模型看不到本机路径，要么逐字内联、要么上传文件）。 + +## 产出文档开头必须有图（单一真源） + +> 2026-10-15 用户令，逐字：「产品规划页面 所有文档前面都要画图」。各段一律引用本节，⛔ 不在段内另写一套口径。 + +- 每份落盘文档**第一屏就给一张图**：图放在标题之后、正文之前 —— 不读正文也能先拿到全貌。 +- 图是**正文内容**，⛔ 不写成标题旁边或标题下面的注解小字（与上面那条排版红线同一件事）。 +- 图要**表达结构或流程**（二选一或兼具）—— 一张图看完就知道「由哪几块组成、怎么连起来」或「一件事分几步走」；⛔ 不做纯装饰性配图。 +- 图表达这份文档**覆盖的东西之间的关系**，按段定画什么： + · ①段（`research/` 五份）—— 画对象与流向：为谁解决什么、信息从哪来到哪去。 + · ②段（文档根 `产品规划/prd/` 两份）—— 画页面骨架：有哪几页、每页几个板块、跨页关系怎么走。 + · ③段（`ui/` 下的产物与 `DESIGN.md`）—— 画页面结构与操作动线：用户办成一件事实际经过哪几页、每页做什么、哪里要来回跳。 + · ④段（产品文档）—— 画页面结构图（各页面与其下的功能编号）＋ 用户路径：各场景怎么串起来。 +- 画图用 `diagram-design`，⛔ 不手写 Mermaid（判据见「工具选择规则」那张表）。 +- 图里每格写清名字、线标方向；图与正文互相对得上 —— 正文新增或改了结构，图要跟着改，两处不许各说各的。 + +## 每段的标准收尾格式 + +``` +## 本段结论 +- （3-5 条，可直接决策的话） + +## 已落盘 +- ... + +## 待确认（最多 3 条） + +## 建议下一步 +→ 用 完成 <具体事> +``` + +## 反面清单 + +- 为一个小功能跑完整调研 +- 输出长文却给不出一个结论 +- 跳过「不做什么」 +- 用户只问单点，却强行拉进全链路 +- 把估算数据写成确凿事实 +- 跳过③段 D0 的 Gate-1（未定死令牌表与设计契约）就开写页面代码 +- 在 `grill-me` 提问模式下仍套用「提问上限 3 个」，把提问做成走过场 +- 只跑一次 `grill-me`：①没定义需求就去取证，或②拿①段的需求定义代替功能压测直接写②段 +- 把自动补全当默认动作：用户没说话就替用户拍板，还没标 `【假设】`、没进待复核清单 +- 手写 Mermaid 代替 diagram-design，手写 token 表代替 DESIGN.md +- 绕过四段自己手搓，或重写它们的内容（该调 `stage-*` 就调） +- 把供给件的内部路径按本 skill 目录去拼，或改它们的正文 —— 供给件指③段自带的 `oil-ui-pro`，以及 §供给 各档落在 `assets/` 下的件（它们是随③段携带的供给件，改动只写 `stage-delivery` 自己的 `SKILL.md` / `references/`；默认档与可选档平行，不缝成一条流水线，也不把 `oil-ui-pro` 的评分循环当成本段 Gate 的替代） +- 猜 `<项目>`：定不出来还硬写，把产物落到别的项目目录下 +- 把 `DESIGN.md` 写到仓库根：多项目会互相覆盖 +- 段间停下来问「要不要继续」：全流程（自动处理）模式下直接进下一段，只在段末输出报告 +- 把两种模式混用：在自动处理模式下自作主张停下问方案，或在「方案确认」模式下确认前就开跑②③④ +- 在「方案确认」模式下把①段的方案当成已确认就往下跑：该模式下①段末必须停下等用户确认（含「不做什么」） +- 下游擅自裁剪上游已拍板项：②③④发现要砍①段或决策表里已拍板的东西时，不许自行裁掉或改口径，必须列成「与已定决策的差异」交用户显式确认 +- 把模式当成段：模式是「要不要在①段末停」的开关，不是第五个段，别为它单独造段或造产物 +- 跑了却不说：没声明当前段 / 子步与依据文件，或偏离了被调 skill 的主流程却不声明、不记偏离单（应为：开工先声明、每个子步再声明、偏离当场声明） +- 让③段顺手把说明区或产品文档写了（那是第④段 `stage-proto-doc` 的活） +- ④段里重新规划产品、重新设计界面，或写原型上没有的页面 / 功能 / 业务规则（④段只解释与记录**现有**原型） +- 问外部模型时堆砌背景：把过程留痕、废弃做法、内部约束清单整段贴进去（应按「征询外部模型（GPT）的提问口径」只给关键背景 ＋ 明确问题） +- 落盘文档开头不给图，或图与正文各说各的（应按「产出文档开头必须有图」先上图、再写正文，两处对得上） +- 过「说人话」时把「注入个性」那半也照做：加观点、加第一人称、写感官细节与比喻、允许跑题（应按内容准则只取「去 AI 味」那半，产出仍是客观书面说明文） + +## 改名 / 改供给后的自检 + +```bash +python scripts/check_naming.py --ws <工作区或产品根> +python scripts/selftest_product_root.py +``` + +`check_naming.py` 查四段段名与子步名在「总入口 ↔ 各段 `SKILL.md` ↔ 各段 `references/`」之间有没有漂，包括 H1 与子步表是否一致、总入口子步列有没有漏项、runbook 必读表有没有引用已移除的资产、两份副本是否一致；顺带按 `--ws` 认出的**产品根**扫 ①②段产出白名单。纯静态比对，不需要渲染，不需要外部依赖。 + +`selftest_product_root.py` 只验一件事：**产品根认得对不对**（造临时夹具，⛔ 不碰真实工作区）。三条路都要成立：单产品时给工作区根 / 给产品根本身 / 从子目录向上都认得出同一层；多产品又没有 `.registry/current-project` 指针时**返回空**（⛔ 不猜、不随手拿第一个，让模型停下来问用户）。认错产品根会把产物写进别的产品目录，事后极难拆干净，所以这条单独立测。 + +为什么必须有它：实测当天漏过两次，当时没有任何门禁会报错。 + +第一次（2026-10-02）：改段名时 `SKILL.md` 改了，但 `references/stage-discovery/references/grill-me.md` 的 H1 仍写「需求澄清（grill-me · 调研段）」；`references/stage-requirements/SKILL.md` 子步表写「2b 功能流转」而正文 H2 写「## 2b 状态机」；总入口④段子步列只写「4a 说明区 / 演示引导」漏了 4b / 4c。三处都只能靠回读发现。 + +第二次（2026-10-06）：②段收窄为「只细化功能」（7 份产出变 1 份）后，各段 `SKILL.md` 都改了，但总入口的三处仍写着旧结构——四段表的②段子步列仍是「2a 功能定义与压测 / 2b 功能流转 / 2c 功能图示」，四段表的①段子步列「1c 产品定位与商业设计」未随段内改名（段内已改称「产品定位与场景」），正文仍写「①与②各跑一次 `grill-me`」并指向两份同名文档，实际全场只有①段一份。闸门当场报 6 个 FAIL，根因是「改了承载段、忘了总入口」。 + +由此立一条硬纪律，与「换供给不能只改承载段」同型：凡改子步结构 / 段内产出清单 / 段间交接口，必须连带改总入口 `product-planning/SKILL.md` 的「四段结构」表与「交接口」表，不改就是半改状态。 + +改了段名 / 子步名 / 判据供给源之后必须跑一次，并把结果记进当日 memory。改完不校验，下次读契约的人拿到的是错的配方。 + +本脚本只查文本一致性（H1 ↔ 子步表 ↔ 总入口 ↔ 副本），查不出「判据口径是否自相矛盾」。例如「②段到底该不该给页面结构」这种反转，闸门一个字都报不出来。口径类改动要靠人工回读，且必须把反转理由与用户原话写进文档留痕。 + +脚本输出里的 `[提示]` 项（旧名出现）不计入失败，但要人工看一眼是不是落在「废止理由块」里——落在里面是正当留痕，散落在正文里就是真残留。 + +2026-10-07 起本技能只在全局一份：技能根下的 `product-planning/`。它就是本体，不再有「主 / 副 / 装入」三副本，也不再需要「三处 md5 复核」（那只在有副本时才有意义）。改完只跑一次 `check_naming.py --ws <工作区>`。用户原话：「把产品规划复制到 workbuddy 全局skills中 后续维护和使用全局技能」。工作区原先那三份已归档到 `归档/技能迁全局-20261007/`（未直删，可随时取回）。 diff --git a/product-planning/references/_留痕/stage-delivery-SKILL-20261016-改自带件前.md b/product-planning/references/_留痕/stage-delivery-SKILL-20261016-改自带件前.md new file mode 100644 index 0000000..936b490 --- /dev/null +++ b/product-planning/references/_留痕/stage-delivery-SKILL-20261016-改自带件前.md @@ -0,0 +1,401 @@ +--- +name: stage-delivery +description: 产品规划第③段，界面交互。设计工程供给默认来自 oil-ui-pro（方法主线与独立评审）加本段自带样式库（定调与令牌），另有可选供给档（本段自带、可选择使用；供给关系见正文 §供给）：先落设计契约与令牌表（Gate-1 硬闸），再构建页面，再收口/动效/终检（Gate-2/3），中途加一轮 GPT 参考版。判据结构为「正向目标为主、禁令只留最关键三条」。当用户要做 UI 规范、设计系统、页面原型、交互动效、界面审查、视觉打磨，或说"只做界面交互"时调用。 +--- + +# ③ 界面交互 + +回答两个问题：长什么样、怎么操作。产出 `产品原型/designs/DESIGN.md` 与 `产品原型/pages/*.html`。 + +> 段名为什么是「界面交互」（2026-10-02 定）： +> 删「交付」：①②③都产出落盘文件，「交付」是三段共有的属性，不是③的专属；④段也在交付（说明区与独立产品文档），留着会让人以为③管完就结束了。 +> 补「交互」：本段原先只讲「长什么样」，可 3b 原型硬要求每个按钮、每个跳转都真能走（`:236`），3c 的参考版对照也要逐项看空态 / 加载 / 错误 / 反馈（`:148`、`:150`）。交互判据一直在做，却没有名字，补上才与本段实际职责相符。 +> 与④段的界：③造物（界面与交互本身），④解释与记录（说明区与独立产品文档，只记现有原型、不重新设计）。 + +> `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。`DESIGN.md` 放项目目录，不放仓库根，避免多项目互相覆盖。 + +## 供给（唯一权威处 · 改供给只改这一块） + +> 🔴 ③段的供给关系**只在本块定义一次**。本文件其余章节、`references/execution-runbook.md`、`references/layouts-tooling.md`、以及总入口 `product-planning/SKILL.md`，提到供给时一律**引用本块的行名**（写成「见 §供给·定调与令牌」这样，行名就取下面那张表的左列），⛔ 不许再复述「谁是默认、路径在哪、装了才有」。 +> 改了供给 ⇒ 只改本块，然后跑 `scripts/check_naming.py`；发现别处有复述 ⇒ 删掉、改成引用。 +> ⚠️ 边界：本块管「有哪几档、谁默认、路径从哪个根起」。各档内部的具体篇目（如可选档工艺判据下的某一篇）属执行细节，留在 `references/execution-runbook.md` 各步里 —— 那些不算复述，改档不会牵动它们。 +> ⚠️ 为什么立这一块（2026-10-08 用户定）：此前这一个事实被复述约 40 处，改一次（默认主线由 `open-design` 换成 `oil-ui-pro`）动三份文件 17 处，仍然漏掉 13 处口径 —— 那是复述式写法必然的代价。单一可信源才拦得住漏改。 + +| 供给位 | 默认来源 | 可选来源 | 管什么 | 用在哪 | +|---|---|---|---|---| +| 方法主线 | `oil-ui-pro`（全局技能，按技能名引用） | 无 | 方向探索 → 建结构 → 取实证 → 独立评审打分 → 验证交付 | 全段；3a / 3d 最重 | +| 定调与令牌 | 自带样式库 `assets/design-systems/<选定一套>/`（随段携带，现 1 套 `design-system-tiaoyue`） | `assets/open-design/design-systems/<选定一套>/`（153 套） | 调性、全套令牌、组件形态。⚠️ **能力边界（2026-10-13 订正）**：自带样式库**不止调色板级** —— `design-system-tiaoyue/assets/component-library/`（采集于 2026-10-12）含 **9 个板块的整页快照**（`snapshot/<板块>.html`，去脚本、图片 URL 绝对化，7 个板块与线上逐像素一致率 ≥99.3%）、**345 个自有组件族**（`gallery.html` 是可视化总库，带搜索与一键复制 HTML）与**整站 CSS 原样合并**（`tiaoyue-all.css`，53 张 sheet ／ 1.11 MB）。⇒ **有目标产品整页快照就直接改快照当原型页**：打开对应板块的 snapshot（`snapshot/<板块>.html`）、改文案、删模块，立刻得到像素级同款的整页；要单个组件就走组件库的「复制 HTML ＋ 引一次 tiaoyue-all.css」。⛔ 仍不许把「供给在位」读成「不必核对」：快照只反映抓取时刻，JS 运行时状态（轮播帧、滚动位置、动态 class）还原不了，那部分要在 3d 里声明为无来源。（本节 2026-10-08 的原表述「只到调色板级…不含源站的界面骨架」写在 component-library 采集之前，已过期作废。） | 3a 的 D1 | +| 版式骨架 | `references/layouts-tooling.md`（工具型页面用） | `<技能根>/open-design/design-templates/web-prototype/`（营销页向；工具型⛔ 不许套） | 工具型九档的名单与判读见 `references/layouts-tooling.md` §0（⛔ 本块不复述名单；2026-10-08 追加「导航栏」一档 = §4.9） | 3b | +| 工艺数值判据 | `references/execution-runbook.md` §3.4 ＋ `references/layouts-tooling.md` §5.5 | `<技能根>/open-design/craft/`（13 份） | 字阶 / 配色 / 状态齐备 / 动效纪律 / 反 AI 味 / 无障碍。⚠️ **未选可选档时，后四项（反 AI 味 / 无障碍 / 动效纪律 / 表单校验）没有供给来源** ⇒ 必须在 3d 审查的留痕件（`产品原型/designs/3d-审查报告.md`，或用 `DESIGN.md` 的〈审查/核对〉节替代；两者都见 §3d「审计报告落盘」）里逐项显式记为**本段证据缺口**（写「无供给来源，本项未判」），⛔ 不许默不作声地跳过、也⛔ 不许拿别的判据冒充它过了 | 3a 判据、3d 终检 | +| 独立评审协议 | `oil-ui-pro` 的 `references/visual-review.md` ＋ `references/tools.md` | 无 | 没看过制作过程的评审打分 ＋ 截图取证 | 3d | +| 多方向比选 | `oil-ui-pro` 的 `references/design-direction.md` ＋ `references/style-explorer.md` | 无 | 方向卡与风格对比页 | 3a 按需 | + +> 🔴 供给是**分层**的（2026-10-08 用户定案）：`oil-ui-pro` 是**基础层** —— 视觉与体验的底线判据都出自它；其余各档（定调与令牌 / 版式骨架 / 工艺数值判据 / 本段自有的 `execution-runbook.md` 与 `layouts-tooling.md`）都是**叠加层**：可以在它之上叠加更多设计规范，只许**更严、更具体**，⛔ 不许**放宽或推翻**基础层。叠加层与基础层冲突 ⇒ **以基础层为准**。 + +> ⭐ 可选来源只有一处：`open-design` —— **同根技能**（装在技能根下）（源 `nexu-io/open-design@0.23.1`，Apache-2.0；署名与裁剪说明见 `<技能根>/open-design/ATTRIBUTION.md`，装在 `<技能根>/open-design/`）。它是**独立技能、可选择使用**：选了才用，不选不影响本段开工。 + +`open-design`（上面那张表的可选来源）给三处，都在 `<技能根>/open-design/` 下： + +1、`design-systems/<选定一套>/`：`DESIGN.md` 定调性 ＋ `tokens.css` 给全套数值（圆角与阴影在这里）＋ `components.html` 给组件形态。 + +2、`craft/`：字号刻度 / 配色配额 / 状态齐备 / 动效纪律 / 反 AI 味 / 无障碍。 + +3、`design-templates/web-prototype/`：种子 `assets/template.html` ＋ 8 个版式骨架 ＋ 自查清单。 + +⭐ 选了自带的 `design-system-tiaoyue` 时怎么读（⚠️ 套内命名与 `open-design` 不同形，别按 `DESIGN.md` 去找）： + +| 要什么 | 套内路径 | +|---|---| +| 入口（规范总纲、生成时的参考范围） | `assets/design-systems/design-system-tiaoyue/SKILL.md` | +| 令牌（含暗色一套） | 同目录 `assets/tokens.css` ＋ `assets/tokens-dark.css`（色值原始记录 `assets/brand.json`） | +| 组件形态 | 同目录 `references/components.md` ＋ `references/design-system.html`（组件族清单 `references/library.json`） | +| 已知冲突 / 取舍记录 | 同目录 `references/known-conflicts.md` ＋ `references/capture-notes.md` | + +> ⚠️ 路径怎么找，按两类分开写：本段**自带件**（`design-capture/`、`design-systems/`）写**段内相对路径**（`assets/design-systems/...`）；**同根技能**写 `<技能根>/<技能名>/`（`open-design` 用 `<技能根>/open-design/...`，`oil-ui-pro` 按技能名引用），与物理位置无关。⛔ 不按绝对路径爬、⛔ 不写死 `../` 层数（位置一变就失效且不报错）。 +> 🔴 定调来源唯一：每次设计只选一套，默认与可选**不混用**（混用 = 没有调性）。套名与选择理由写进 `DESIGN.md`。 +> ⛔ 判据正文仍只在本段（`references/execution-runbook.md` 与 `references/layouts-tooling.md`）。⚠️ 供给是分层的，分层定义见 §供给：`oil-ui-pro` 是**基础层**，本段自有判据是**叠加层**；同一条判据两处都有且口径不同时，⛔ 本段不许放宽基础层，只许更严、更具体，并在 runbook §3.4 标注「本项目追加」。 +> ⛔ 不许把 `oil-ui-pro` 的评分循环当成 D 阶段的替代：它是评审方法，Gate-1/2/3 该过还得过。 +> ⛔ 不动用可选来源时，⛔ 不许凭感觉编一套顶上（那正是本项目反复踩的坑）；craft 独有的那几项（反 AI 味 / 无障碍 / 表单校验 / 动效纪律）明说「本次无供给来源」。 +> ⚠️ `oil-ui-pro` 自带联网版本检查与自动更新（每次使用会连 `ui.oiloil.org`，发现新版用 `npx` 覆盖自身目录）。这是本项目收录时用户明确要求全量搬入的例外项，与「依赖外部服务一律不收」的既有纪律冲突，记录在案，不扩散到其他技能。想关掉设环境变量 `OIL_NO_UPDATE_CHECK=1`。 +> 供给件都不依赖付费云 / MCP / API Key 才能用于设计：`open-design` 去掉那些之后剩下的全是静态 md / css / html（其 daemon、云模型服务、`packages/components` 的 tsx 未收录）；`oil-ui-pro` 的设计方法**不依赖目标产品**、离线可用（联网仅用于版本检查）。 +> 冲突处以 §供给·方法主线（基础层）为准；本段自有判据与 `DESIGN.md` 是叠加层，只许更严，⛔ 不许与基础层相反。供给件的价值在给正向目标、给方法。 + +> 为什么换掉原来的主干（2026-10-02 用户定案）：原主干 `ui-page-design` 已从磁盘移除，③段只剩规则壳，壳里又全是减法型判据，机检能判「不违规」却判不出「好看」，18 轮回改把页面越推越白。换供给的同时必须换判据结构：正向目标为主，禁令只留最关键的。 + +> ⭐⭐ 本段在②段给定的骨架里做视觉与交互（2026-10-06 用户定案）。 +> +> 口径：②段钉骨架，③段做皮肉。 +> +> 🔴 「②段管什么、本段管什么」的完整清单（含两侧逐行对照）只在②段 `references/stage-requirements/SKILL.md` +> 的 §②—③ 交接口 定义一次 —— ⛔ 本文件不复述那张表，免得两处漂。用户原话也放在那一节，此处不再抄。 +> +> 🔴 旧口径站不住的地方：它把「有哪几页」留在本段，于是本段做一版一个样，②段手里没有任何东西能判断本段改得对不对。 +> ⭐ 本段拿到的骨架是冻结的：⛔ 不许新增 / 移动 / 删除板块。缺板块要回②段改②段（见「硬约束」的对应禁令）。 +> +> 仍在本段手里的两个字段（它们在给定骨架之内决定怎么摆得好看）： +> - `必要内容`（减法）：⚠️ 口径已调整。它不再决定哪些内容上屏（那是②段分档表的活），而是核对②段给的信息是否都在骨架里有落点；⛔ 本段不得以它为由增删信息档位。 +> - `结构骨架`（加法）：⚠️ 口径已调整。它不再独立决定几个区块，而是把②段给的板块清单翻译成具体的骨架档 / 列宽 / 密度目标（骨架档选哪个、密度多少，仍是本段的活）。 +> +> ⛔ 本段不许回头改②段的骨架（那是②段）；⛔ 也不许无视②段骨架自己另起一套。判据：D0 里的页面清单与每页板块，必须与②段《界面布局》逐条对得上；对不上就停下来问②段要哪一版。 + +顺序 3a → 3b → 3c → 3d。先有规范再出原型，不许反过来；原型能点通后先取一份外部参考版，再收口打磨。 + +> 照 `references/execution-runbook.md` 逐步走。那是本段的固化执行手册：按 D 阶段排的必读表、每步验收判据、脚本跑法、偏离单格式、完成标准清单都在里面。本文件写规则，手册写顺序与验收。 +> 开工前先声明、每进一个子步再声明、偏离当场声明（三字段：当前子步 / 依据文件 + 小节号 / 产出落点）。这条不可商量。 + +## 子步与产物 + +| ③段子步 | 做什么 | 产物 | 闸 | +|---|---|---|---| +| 3a 视觉规范 | 定契约（减法 + 加法）→ 定调（选定设计系统）→ 落令牌表〔方法主线按 `oil-ui-pro` 的方向探索走；要拉开方向让用户挑时用它的对比页〕 | 设计契约 + 令牌表 → `DESIGN.md` | Gate-1 方向门 | +| 3b 原型 | 按模板种子 + 版式骨架构建 | `产品原型/designs/<原型>.html` | — | +| 3c GPT 参考版 | 让 GPT 按需求＋风格**独立生成一版当参照物**（本段特有，两个设计技能都不覆盖） | `3c-GPT参考版.md` | — | +| 3d 审查与打磨 | 收口 → 动效 → 终检〔按 `oil-ui-pro` 的评审协议做一轮独立评审打分〕 | file:line 清单 + `3d-审查报告.md` | Gate-2 / Gate-3 | + +挡位开工前定一次，默认标准：纯原型可降快速（定契约 → 定调 → 构建 → 终检）；常规页面走标准（全跑）；对外页面走严格（三闸全开 + 中间产物落盘）。 +`Gate-1` 与 `Gate-3` 是硬闸，任何挡位都不可跳，哪怕只做原型，也要打开看一眼。 + +## 三条铁律（只留不可省略的） + +| # | 铁律 | 违反后果 | +|---|---|---| +| 1 | 先定死，再写码。未产出设计契约与令牌表前，禁止写任何组件代码；禁止边写边调样式。 | 返工、风格漂移 | +| 2 | 状态穷举。`loading / empty / error / success / disabled / 无权限` 逐项给结论（判据见 §供给·工艺数值判据）。 | 上线即翻车（最高频漏项） | +| 3 | 不渲染不算完。交付前必须在真实环境渲染一次并肉眼确认。 | 裁切/重叠/失效控件逃过检查 | + +> 禁令就这三条，其余一律去 §供给·工艺数值判据 里查（默认档按本段两份的对应章节；可选档按其工艺篇目，逐篇见 §供给·工艺数值判据）。 +> ⛔ 不在本文件里抄写禁令清单。抄了就变两份，两份必然漂；更要紧的是，抄禁令会把正向目标挤出视野，这正是改版前③段只剩「不要什么」、页面越改越白的根因。 +> 一条例外（本项目特有，供给件里没有）：结构性容器靠底色差 + 阴影分层，不挂围合边框（来源：本项目 E-62 / E-63 实测）。当选定设计系统写「卡片描边」时，以本条为准。 +> 限载：同一时刻只读 1~2 份供给原文，用完释放。这条不再单列铁律，但仍是硬约束（可选档定调候选与工艺判据份数都不小，全读必然互相稀释）。 + +## 必读（限载：一次只读 1~2 份，用完释放） + +| 环节 | 取哪些供给位（定义见 §供给） | +|---|---| +| 3a 方法主线 | §供给·方法主线 | +| 3a 定调 | §供给·定调与令牌（默认档；要用可选档就在 `DESIGN.md` 写明理由）。入口 / 令牌 / 组件形态按 §供给 里的「套内怎么读」取 | +| 3a 判据 | §供给·工艺数值判据（本项目追加条在 `references/execution-runbook.md` §3.4） | +| 3a 多方向比选（按需） | §供给·多方向比选 | +| 3b 构建 | §供给·版式骨架 ＋ §供给·工艺数值判据（工具型只取默认档） | +| 3d 独立评审 | §供给·独立评审协议 | +| 3d 终检 | §供给·工艺数值判据 ＋ §供给·版式骨架 | + +> ⚠️ 3b 只取 §供给·版式骨架 的默认档。可选档那套（`web-prototype`）是营销落地页向，只在判「要不要套它的流程」时读。 +> ⚠️ 本表只写「哪一步取哪个供给位」，⛔ 不写路径、不写默认判断 —— 那些只在 §供给 定义一次。 +> 本段 `references/` 只放流程规则，⛔ 不放风格；随段携带的样式风格一律放 `assets/design-systems/<套>/`（🔴 2026-10-07 用户令两条：「把 `design-system-tiaoyue` 整合到 `product-planning` 作为一种样式风格」＋「后续可以添加多种风格，每次只能选择一种进行设计」⇒ 只把「不放风格」这条放宽到 `assets/`，`references/` 仍不放）。 +> ⚠️ 续加新风格时的硬要求：目录名与可选档同形（`assets/design-systems/<套名>/`），套内自带入口文件（`SKILL.md` 或 `DESIGN.md`）；⛔ 不许改已入套的文件内容，原样搬入、只在本文件登记去向。 +> 🔴 定调来源唯一（两档见 §供给·定调与令牌）：每次设计只选一套，⛔ 不许混用两档（混用 = 没有调性）。套名与选择理由写进 `DESIGN.md`。 +> 既有项目中凡引用旧风格来源（`minimalist-ui` / 皮肤族 / `ui-ux-pro-max` 检索结果）的 `DESIGN.md` 行，重跑 3a 时一律改写为选定套 + 留痕对照。 + +## 3a 视觉规范（定契约 + 定调 + Gate-1） + +第 0 步 · 供给核对（每轮必做，防漂移）：按 §供给 逐档核对在位 —— 默认档必核，可选档**选了才核**（其可选来源那三处，见 §供给 表）。核完把选定套名与 `DESIGN.md` 里记录的上次套名比对。 + +- 一致 → 直接定契约。 +- 不一致或供给缺失 → 先停下报告，⛔ 不许拿别的套顶上，也不许凭记忆写风格。把差异列成「供给变更清单」，在会话里向用户呈现并确认后，再改 `DESIGN.md`，把新套名与清单写进修订记录。 +- 本步存在的理由：`DESIGN.md` 是上一次供给状态下产出的。供给换了却没核对，就会长期拿着旧调性当准绳。 + +D0 锚需求：按 `references/execution-runbook.md` §2.1 的契约模板产出设计契约（十二个字段）。字段清单与逐条判据以 §2.1 为准 —— ⛔ 本文件不重复列，免得两处漂。 + +> ⭐⭐ 第十二字段「交互清单」是 2026-10-02 新增，段名改名的直接后果（段名从「界面与交付」改成「界面交互」，但「交互」在流程里此前没有落点：可点通在 3b、查反馈在 3c、动效在 3d，三处各判一部分，谁也不负责整体）。 +> 它写什么：逐个可点元素一行，四列——元素（哪个）｜触发（点了/输了/滚到哪，发生什么）｜反馈（状态怎么变、给什么提示、多久消失）｜何时不可点（哪些条件下 `:disabled`，条件是什么）。 +> 它不写：动效参数（归 3d 按 §供给·工艺数值判据）、视觉样式（归令牌表）、状态六项的有无判定（归下一字段 `状态覆盖`，本字段只写「这个元素可点时点了会怎样」）。 +> 为什么是契约字段而不是新子步：交互一旦单独成文，就会与 `必要内容`、`状态覆盖` 三处互相矛盾——这正是记忆里「同一事实多处落点必然打架」的病。收进契约 = 一个字段、一处裁决、一个门禁。 +> 判定「漏没漏」：页面里每一个能点的东西都必须在这张表里出现。表里没有 ⇒ 它不该可点（改成静态文本，或回 D0 补进 `必要内容` 再点）。 + +D1 定调：从 §供给·定调与令牌 的默认档里选一套；要用可选档就从可选档里选（⛔ 每次只选一套，两档不混用），不凭感觉编，也不全读： + +- 怎么选：按本项目的页面类型挑。读候选套 `DESIGN.md` 的第 1 章 `Visual Theme & Atmosphere`，认准写明该类的那一句（工具型数据密集界面 ⇒ 认 `data-dense, enterprise` 这类描述）。可选档的候选分两代模板（A 组 / B 组章节名不同），按自己那套的章节读，不必统一。 +- ⚠️ 选了自带库那套（`design-system-tiaoyue`）时：套内没有 `DESIGN.md` ⇒ 读它自己的 `SKILL.md`（规范总纲 ＋ 生成时的参考范围）＋ `references/known-conflicts.md`（已知取舍）；入口 / 令牌 / 组件形态按 §供给 里那张「套内怎么读」表取，⛔ 别按可选档那套的三件套去找。 +- 选定后读三件：`DESIGN.md`（调性 + 色值 + 字号刻度 + 间距刻度 + 动效基调）→ `tokens.css`（圆角与阴影只有这里）→ `components.html`（组件实际长相）。 +- 要换风格 ⇒ 下一轮重跑 D1 重选一套，旧套留痕（用户 2026-10-07：「后续可以添加多种风格，每次只能选择一种进行设计」）。 +- 没找到匹配的套 ⇒ 换一个类型词再挑一次；仍不行就直说「未找到匹配」，不许拿泛化结果当结论落盘。 +- ⚠️ 工具型页面的版式不在可选档的模板里（可选档是营销页向；骨架名单与理由见 `references/layouts-tooling.md` 开头）。工具型页面的版式由 D0 的 `结构骨架` 字段决定，不从模板抄。 + +- 产出令牌表：色值 / 字体（标题字体是关键项）/ 间距两档（主刻度 `4/8/16/24/32/64` 供布局 + 控件层微网格 `2/4/6/8/12` 仅供按钮内衬、徽章内衬、图标间隙、开关与进度轨微几何）/ 圆角 / 字阶定值表（七档各一个 px，不是区间）/ 高度层级（每层都有多层叠层值）/ 布局脚手架（骨架档落到具体列宽 + 窄屏变化）/ 组件规格（按钮三档 + 卡片两档 + 输入框 + 徽章的具体高度与内衬；实底底色 ≥2 种）/ 动效基调——全部为具体值，禁止「待定」，每档只许一个定值 + +落盘 `产品原型/designs/DESIGN.md`：令牌表内容并入本项目既有的三层 token 结构（primitive → semantic → component；组件只引语义层、语义层只引 primitive），设计契约作首节。`DESIGN.md` 是原型的绑定规范，原型只许引它的 token。 + +Gate-1 方向门（硬闸，不可跳）——按本表逐项自检（字段定义与填写位见 `references/execution-runbook.md` §2.1；⛔ 供给件没这一项，十二字段只能在此判）： + +| 检查项 | 通过条件 | +|---|---| +| 设计契约 | 十二个字段全部填写，无一为空或「待定」；有重复项时重复项的信息量已逐条列出次级信息 | +| 页型判定（2026-10-05 新增） | 已写出「营销页还是工具型页面」+ 依据；工具型页面的 D0 里零 `.eyebrow` / 零 `.lead` / 零 `.hero` | +| 结构骨架（加法面） | 骨架档 / 区块划分 / 密度目标三者已写；区块 ≥2 个且每个有文字标题；`必要内容` 每条都有归属区块 | +| 交互清单（加法面，2026-10-02 新增） | 页面上每一个可点元素都在表里（元素 / 触发 / 反馈 / 何时不可点 四列齐全）；表里没有的可点元素为 0 | +| 状态覆盖 | 六个状态逐项有结论（勾选，或「不适用 + 理由」） | +| 令牌表 | 色值 / 字体 / 间距两档且适用面已分开写 / 圆角 / 阴影全为具体值 | +| 字阶定值表 | 七档每档一个 px 定值（不是区间）；相邻档差 ≥2px；每档只许一个定值 | +| 高度层级 | 每层都有多层叠层值；同层级同值 | +| 布局脚手架 | 骨架档已落到具体列宽；窄屏变化写具体 | +| 组件规格 | 按钮三档 + 卡片两档 + 输入框 + 徽章均为具体值；同一父区块内主档 ≤1；实底底色 ≥2 种 | +| 供给核对（本项目附加） | 按 §供给 逐档核对在位（默认档必核，可选档选了才核）；选定套名与 `DESIGN.md` 记录一致；不一致则变更清单已确认并写入修订记录 | +| 反 slop | 无紫→粉渐变、标题未用禁用字体、强调色已写明允许位置 | +| 拒绝清单 | ≥3 条，且每条可判定 | +| token 引用完整性（本项目附加） | 语义层只引 primitive、组件层只引语义层、无孤立 token | + +任一项不过 → 停在 3a 补齐，不进 3b。 + +> 对比度门槛见 §供给·工艺数值判据 里配色那一份（数值登记在 `references/execution-runbook.md` §3.4 的数值判据段），由终检阶段按真实像素复测（静态算不准 CSS 变量叠加后的结果）。 +> 已知环境问题：`npx @google/design.md lint` 在本机完全不可用（alpha + clack 交互库，非 TTY 管道下静默且 exit 0）。不要拿它当校验关卡，也不要因它无输出就认为通过。 + +## 3b 原型（构建） + +> ⛔ 开工前先判页型（2026-10-05 新增，硬前置）：写下「本页是营销页还是工具型页面，依据是什么」。 +> 两种页型的目的不同，骨架不能通用：营销页目的是说服（主张 → 论据 → CTA），工具型页面目的是完成一件工作（数据 + 操作）。 +> 判别口径：要用户「下决心去做某事」⇒ 营销页；要用户「把这件事做完」⇒ 工具型页面。⚠️ 判不准时按工具型处理（默认取严）。 +> 判不出来不许进 3b，停下来回改 D0 的 `结构骨架`。 +> 🔴 为什么这条是硬前置：§供给·版式骨架 可选档那套的种子 `assets/template.html` 是营销落地页骨架，自带 `.eyebrow`（眉标）与 `.lead`（副标题）。不判页型就照种子做，会得到「标题上方一行小字 + 大标题 + 下方一行灰色小字」的三段式——那是 2026-10-05 用户实测指出「像实习生画的」的唯一根因，而且结构判据全绿（判据判类名合法性，判不出「这不是工具界面的排版」）。页型不判，后面换什么设计系统都救不回来。 + +要选可选档时，可按它那份 `SKILL.md`（§供给·版式骨架 的可选档）的六步走：读种子 → 把 `assets/template.html` 复制成 `index.html` 并替换 `:root` 令牌 → 先定版式节奏再粘骨架 → 填充 → 自查 P0/P1/P2 → 落盘。不选它就按默认档（`references/layouts-tooling.md`）的骨架与落地自检走。两条路线都要求「先选定一个明确的美学方向再写码」，与铁律 1 同向。 + +- ⭐ 工具型页面先判形态，再挑骨架（2026-10-02 新增）：读 §供给·版式骨架 的默认档。本项目是工具型数据密集界面，可选档那套是营销页向、与本项目不匹配（名单与理由见 `references/layouts-tooling.md` 开头）。 + ⚠️ 两份工具型文件的分工（2026-10-05 补）：本技能 `references/layouts-tooling.md` 给可粘贴 HTML 骨架 + 逐条判据正文（§5.5），是默认档；选了可选档时，它那份 `tooling.md` 另给四形态判定句 + 通用红线纲要，只作指路。⛔ 判据只在 `layouts-tooling.md` 展开，`tooling.md` 只指路，两处展开必然漂。 + 形态判定一句话：页面上能数出「并列的同类记录」⇒ 列表型（工具型默认首选）；数不出、页面围绕单个对象展开 ⇒ 详情型；主操作要在两个工作面之间来回 ⇒ 侧区型。 + ⛔ 不许拿营销页骨架顶替工具型，那是「没做形态判定」的默认行为，等于退回 18 轮前的病根。判不出形态就去改 D0 的 `结构骨架` 字段，⛔ 不许随手挑一个。 +- ⭐ 先看供给里有没有**目标产品整页快照**（`assets/design-systems/<选定套>/assets/component-library/snapshot/<板块>.html`）：有 ⇒ 复制快照当原型页，改文案、删模块；没有 ⇒ 才判页型挑骨架。⛔ 不许从零手写 `
`。用了可选档时，可选档那套的 `layouts.md` 开头的类清单（`section` / `container` / `card` / `btn-primary` / `grid-3` …）必须在种子 `template.html` 的 ` + + +
+ +

<产品名> · 产品文档

+ +

+ 用法：把带 <尖括号> 的占位全部换成真实内容，删掉本节上面的示例行， + 再按第④段要求逐节填。编号口径：页面 P001…／使用场景 S001…／功能 F001…／二级功能 J001…，各自全篇唯一、按展示顺序通排。 +

+ +

一、原型页面地址

+ +

每个原型页一行相对链接（文件名 ＋ 一句它是什么），放文档最前；⛔ 不写本机绝对路径，⛔ 不写说明句 —— 读者直接点开就行。

+ +

二、页面结构

+

先给一张结构图，再列功能。页面框里按**功能区**分块，每个功能区画成自己的板块盒；连线只画真实存在的跳转，并在标签上写清触发动作。

+ + + + + + + + + + + + 入口：<从哪个页面> → <点什么> → <进到哪> + + <页面 A> + <一级页面> + + + <功能区名> + F001 <功能名> + F002 <功能名> + + + <页面 B> + <二级页面> + + + <功能区名> + F003 <功能名> + F004 <功能名> + + + <页面 C> + <独立页面> + + + <功能区名> + F005 <功能名> + + <触发动作> + + + <退回动作> + <触发动作> + + + + +

三、功能清单

+ +

页面功能

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
序号页面名称层级功能区功能功能做什么租户待开发
P001<页面 A><一级页面><功能区名>F001 <功能名><一句话说清它做什么、有什么限制>全部租户✓
<功能区名>F002 <重点功能名><重点功能用红字标出>麦芽租户✓
P002<页面 B><二级页面><功能区名>F003 <功能名><一句话说清它做什么>全部租户✓
<功能区名><待确认><待确认>全部租户✓
+

页面上每一项都要有 F00x 编号；页面序号／页面名称／层级合并格，功能区按区合并格；暂时没登记到功能的板块照样占一行，两格写「待确认」。

+ +

<二级功能名>（二级功能）

+

技能、模板这类**选项值**属于二级功能：它们由页面功能 <F00x 功能名> 承载，在这里**引用**那个页面功能，自己不再占 F 编号。

+ + + + + + +
序号二级功能项产出什么对应页面功能
J001<选项一><产出什么><F00x 功能名>
J002<选项二><产出什么><F00x 功能名>
+ +

重点说明

+ + + + + + +
重点项说明相关编号
<重点项一><为什么是重点、它覆盖哪些能力><F00x、F00x>
<重点项二><为什么是重点><F00x>
+

上述功能为本次新增功能。

+ +

四、使用场景

+ + + + + + + + + + + + + +
序号场景含几条流程优先级待开发对应功能
S001<用户要办成的一件事><N> 条P0✓<功能名（F00x）>、<功能名（F00x）>
S002<用户要办成的另一件事><N> 条P0✓<功能名（F00x）>
+

共 <N> 条使用场景，含 <N> 条流程、<N> 个操作步骤。

+

判定口径：用户通过产品功能办成、且**拿到一个结果**的才叫一件事；起手、分支、异常、同一件事的两种手法都并回所属那件事。拿不到结果的（进到某个页面、确定某个取值）不列为场景，只作功能步骤。

+ +

五、操作流程

+

每条流程画成一张**横向**流程图：步骤盒自左向右排、箭头横向连接；每个盒自带标题栏（只放步骤名），正文写页面／功能／操作／完成判据；**「操作」那行用强调色**。

+ +
+

S001　<场景名>

+

<这条场景是在什么前提下、办成什么事>

+ +
流程 1　<流程名>
+ + + + + + + + + + 1. <步骤名> + 页面：<页面名> + 功能：<F00x 功能名> + 操作：<这一步怎么操作> + <操作的续行> + 完成判据：<界面停在哪个状态> + + + + 2. <步骤名> + 页面：<页面名> + 功能：<F00x 功能名> + 操作：<这一步怎么操作> + 完成判据：<界面停在哪个状态> + + + + 3. <步骤名> + 页面：<页面名> + 功能：<F00x 功能名> + 操作：<这一步怎么操作> + 完成判据：<本件事最后一步> + + + + + + +
流程 2　<另一条流程（异常／等待等）>
+

同一件事下的分支、加载中、失败，都作为这条场景的**另一条流程**，不另起一节。

+
+ +

六、页面导航

+

<来源页> → <目标页>：<走法>。

+

<来源页> → <目标页>：<走法>。

+

<来源页> → <目标页>：<走法>；<单向跳转与打开方式>。

+

一条导航一段，标签写「来源页 → 目标页」，正文写走法；⛔ 不在这里写界面状态 —— 那归第七节。

+ +

七、原型状态取值

+

<界面状态用地址后的哪个参数指定；不带参数时落在哪个界面>。

+ + + + + + +
取值界面
<取值一><落在哪个界面>
<取值二><落在哪个界面>
+

取值与状态名一律以原型为准；⛔ 不把页面层级当状态写。原型没有这套机制时，整节写「无」。

+ +
+ + diff --git a/product-planning/references/_留痕/stage-proto-doc/references/doc-area-spec.md b/product-planning/references/_留痕/stage-proto-doc/references/doc-area-spec.md new file mode 100644 index 0000000..3299bc2 --- /dev/null +++ b/product-planning/references/_留痕/stage-proto-doc/references/doc-area-spec.md @@ -0,0 +1,73 @@ +# 原型说明区规范 + +> 本文件是 `stage-proto-doc` 的方法论文档，由模型按需加载，没有斜杠命令。 +> 骨架与 `assets/产品文档模板.html` 同构 —— 说明区就是独立产品文档的七节，嵌进原型对应位置。两份产物共用同一套编号、场景、流程与功能定义。 + +## 定位 + +说明区是原型自带的注解层，不是产品功能。它不回答"长什么样"，回答的是： + +> 站在这个界面上，我这一步在干什么、我能输入什么、什么情况下它不给好脸色。 + +所以它贴在原型对应位置的下方，随当前所在的页面一起变。抽出来单独写一份，读者就得自己脑补对应关系。 + +## 七节怎么落进原型 + +- **一、原型页面地址**：每个原型页一行相对链接（文件名 ＋ 一句它是什么），放在文档最前；⛔ 不写本机绝对路径、⛔ 不写说明句。 +- **二、页面结构**：页面结构图放原型首页顶部，图上标出各页面与其下的功能编号（页面 `P00x`／功能 `F00x`）。 +- **三、功能清单**：表格贴在对应功能区下方 —— 列：编号／页面／层级／功能区／功能（`F00x` ＋ 名称）／功能做什么／功能细节／目标产品特有列（本项目＝租户列）／待开发；二级功能另起一张表（`J00x`／二级功能项／产出什么／对应页面功能）。重点功能在功能名、说明、目标产品特有列三处同时标红。 +- **四、使用场景**：每个场景一段，带前提／目标／原型位置（写到「页面 → 模块 → 控件或状态」，能在原型上点到）。 +- **五、操作流程**：每个场景一条横向流程图，规则见下节。 +- **六、页面导航**：一条导航一段，写成「来源页 → 目标页」＋走法；单向跳转与打开方式写明。 +- **七、原型状态取值**：一行一个取值，写清取什么值落在哪个界面；取值与状态名以原型为准。 + +## 场景怎么写 + +- 粒度是"人要完成的一件事"，不是一个按钮。"提交驳回"不算场景，"驳回一条片段并完成失败模式归类"才算。 +- 一个页面下的场景数控制在 2–4 个。1 个说明不了分支，5 个以上就该拆页面或拆功能区。 +- 顺序按发生频率排，不按界面从上到下排。 +- 前提一句话写清。例："预审排队、执行中或失败时人工仍可决策，但必须清楚自己在无依据的情况下决策。" + +## 横向流程图 + +| 规则 | 说明 | +|---|---| +| 形态 | 横向 `ol`，每项 = 序号圆点 + 步骤名，项间一个 `→` 箭头 | +| 每步内容 | 写清 页面／功能／操作／完成判据，「操作」行用强调色 | +| 溢出 | 横向滚动，不换行 —— 换行会读成两条并行流程 | +| 步数 | 2–6 步：超过 6 步说明这个场景该拆，1 步说明它还不算流程 | +| 交互 | 点步骤 → 下方出这一步的四项说明；再点收起；同级只选中一个 | +| 键盘 | 步骤是 `button`；`aria-current` 标当前项；说明区 `role="region"` 带 `aria-controls` | +| 箭头 | `aria-hidden`，它只是视觉连接符，不进朗读 | + +## 每项功能的四项要求 + +| 项 | 回答的问题 | 合格判据 | 不合格示例 | +|---|---|---|---| +| 做什么 | 这一步做什么、给谁看、落笔后产生什么 | 换一个组件这句话就不成立 | "展示相关信息，提升审核效率" | +| 入口在哪 | 可定位的页面与控件 | 能在原型上点到 | "相关入口" | +| 输入边界 | 取值域 / 上限 / 前置条件 / 必填与选填 | 说得出"什么不被接受"或"最多几条" | "支持筛选" | +| 异常与恢复 | 失败 / 空 / 禁用 / 重复提交 / 恢复路径 / 文案红线 | 至少一种"坏了怎么办"，且给出出路 | "暂不支持" | + +写输入边界，常见切入点：数量上限、字数或时长范围、哪些状态才可用、必填项有哪些、一次作用于一条还是全部。 + +写异常与恢复，常见切入点：加载中能不能点、失败了怎么重试、重复提交怎么挡、空的时候显示什么、禁用要不要给原因、文案不能写成什么。 + +### 文案红线 + +- 不得把自动结论表述为人工认可。机器判定只能说"进入队列 / 待人工逐条查看"，不写成"通过 / 已认可 / 已确认"。 +- 不用无法区分成因的笼统文案。"暂无数据"要拆成"批次为空"与"筛选无结果"两条出路。 +- 不承诺原型里点不出来的能力。说明区每条都要能在原型上指到对应元素。 +- 异常态必须给恢复路径。只写"失败了"不算说明，要写清楚下一步按哪里。 + +## 自查（逐条打勾） + +- [ ] 七节都落到原型对应位置，顺序与模板一致 +- [ ] 页面 `P`／场景 `S`／功能 `F`／二级功能 `J` 各自唯一且按展示顺序通排 +- [ ] 每个场景 2–6 步，每步写清页面／功能／操作／完成判据 +- [ ] 每项功能的四项都填了，且各自能通过上面的合格判据 +- [ ] 重点功能在功能名、说明、目标产品特有列三处同时标红 +- [ ] 全文没有"通过 / 已认可"这类把机器结论说成人审的词 +- [ ] 每个禁用态都给了原因，每个异常态都给了恢复路径 +- [ ] 说明区文案与②段术语逐词一致 +- [ ] 点不出结果的场景已标 `funcOnly`，并在段末待确认清单里写明为什么点不出来 diff --git a/product-planning/references/_留痕/stage-proto-doc/references/doc-language-spec.md b/product-planning/references/_留痕/stage-proto-doc/references/doc-language-spec.md new file mode 100644 index 0000000..0b6dd10 --- /dev/null +++ b/product-planning/references/_留痕/stage-proto-doc/references/doc-language-spec.md @@ -0,0 +1,322 @@ +# 产品文档语言规范 + +> 来源：ChatGPT 网页版（2026-10-14，会话 `6acf7fc1-8d10-83e8-b328-8e885f5efb8c`）。 +> 用法：写④段的两份产物时逐句过一遍；第五节自检清单任一项不通过就改。 +> 它管**语言**；文档骨架（七节：原型页面地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值）见上一级 `SKILL.md`。 + +--- + +## 一、语体与句式 +### 1.1 语体要求 + +使用客观、正式、书面的说明文语体。 + +面向产品、开发、设计人员，确保读者不查看原型也能理解文档内容。 + +描述系统行为时使用可验证的事实，不使用主观评价或个人感受。 + +区分已实现行为、计划行为、未实现行为和待确认事项。 + +不使用聊天式表达、营销式表达、口号式表达或未经证实的效果承诺。 + +### 1.2 句式要求 + +一句话只表达一个主要意思。 + +一个句子只描述一个主要动作、判断、规则或结果。 + +存在多个独立动作时，拆分为多个句子，并按执行顺序排列。 + +存在条件关系时，明确写出条件和对应结果。 + +存在因果关系时，明确写出原因和结果，不使用含糊的连接词。 + +描述操作时，优先使用「操作主体＋动作＋对象＋结果」句式。 + +描述规则时，优先使用「适用条件＋处理规则＋预期结果」句式。 + +描述异常时，明确异常条件、系统反馈和恢复方式。 + +删除不影响事实含义的铺垫、重复解释和语气修饰。 + +不得为了追求简短而省略执行主体、操作对象、条件或结果。 + +### 1.3 句子验收标准 + +一个句子包含两个及以上可独立执行的动作时，拆句。 + +一个句子包含两个及以上独立判断条件时，按规则复杂度拆分或使用列表。 + +句子出现代词时，必须能够从当前句或明确的上下文唯一确定指代对象。 + +句子出现条件时，必须能够判断条件成立与不成立时的处理方式。 + +句子描述完成状态时，必须给出可观察或可判断的完成标志。 + +## 二、名词与术语 +### 2.1 术语来源优先级 + +按以下顺序确定文档中的术语： + +原型界面上实际显示的页面名、模块名、按钮名、字段名和状态名。 + +已确认的产品需求、功能定义及业务术语表。 + +行业内含义明确且与当前业务一致的通用术语。 + +无法从以上来源确认的术语，标记为「待确认」，不得自行创造。 + +### 2.2 界面名称使用规则 + +界面已有名称时，文档必须使用原名称，不得随意改写、缩写或替换同义词。 + +首次提及界面元素时，使用完整名称。 + +同一对象在全文中必须使用同一名称。 + +页面名、模块名、控件名、字段名和状态名不得混用。 + +界面名称与业务概念不一致时，分别说明界面名称和业务概念，不得强行合并。 + +原型中没有名称的元素，不得擅自赋予正式名称；必要时使用位置描述并标记「待命名」。 + +引用按钮、菜单、字段或状态时，使用其实际显示文本，并通过引号或上下文明确其为界面名称。 + +### 2.3 新术语与未知术语处理 + +新术语必须有明确的业务定义、使用范围和来源。 + +同一概念存在多个叫法时，确定一个标准名称，其余叫法仅在必要时作为别名说明。 + +不得通过拼接常见词语创造未经定义的产品术语。 + +不得将技术实现名称直接当作用户可见的功能名称，除非产品资料明确采用该名称。 + +不得把个人理解、推测或临时命名写成已确认的业务定义。 + +无法确认术语含义时，记录待确认事项，不得通过上下文猜测后直接定稿。 + +### 2.4 指代与缩写 + +不使用指向不明确的「它」「这个」「相关内容」「上述功能」。 + +可以唯一定位对象时，直接使用对象名称。 + +缩写首次出现时，应给出中文全称及必要的英文全称。 + +缩写在全文中必须保持一致，不得交替使用全称、简称和自造简称造成歧义。 + +## 三、禁用清单 + +以下词语和句式在正式产品文档中一律禁用。确需表达对应含义时，必须替换为明确、可验证的描述。 + +### 3.1 聊天式表达 + +「我们可以……」 + +「你可以……」 + +「用户只要……就行」 + +「点一下……」 + +「然后就……」 + +「这个地方……」 + +「这里的话……」 + +「其实就是……」 + +「简单来说……」 + +「大概是……」 + +「差不多……」 + +「之类的……」 + +「等等」「诸如此类」 + +### 3.2 空泛动词与模糊表达 + +「搞定」「弄好」「处理一下」 + +「做一下」「操作一下」「配置一下」 + +「支持相关操作」 + +「进行相应处理」 + +「展示相关信息」 + +「提供便捷能力」 + +「实现快速处理」 + +「优化体验」 + +「提升效率」 + +「满足用户需求」 + +「智能处理」「自动优化」——未明确处理规则时禁用。 + +「实时更新」「快速响应」——未定义时效或判定标准时禁用。 + +「灵活配置」「多种方式」「丰富内容」——未列出具体范围时禁用。 + +### 3.3 无明确依据的程度词 + +「非常」「特别」「极其」 + +「十分方便」「十分简单」 + +「更加友好」「更加完善」 + +「高效」「便捷」「流畅」 + +「强大」「先进」「全面」 + +「无缝」「极致」「完美」 + +「大幅提升」「显著改善」 + +「一键完成」「秒级完成」——未验证对应行为或性能时禁用。 + +### 3.4 含糊的指代与范围词 + +「相关页面」「对应位置」——未给出具体名称或路径时禁用。 + +「相应内容」「相关信息」——未说明具体对象时禁用。 + +「适当提示」「必要时处理」——未定义触发条件时禁用。 + +「部分数据」「一些情况」「某些用户」——未限定范围时禁用。 + +「正常情况下」「特殊情况下」——未定义条件时禁用。 + +「根据实际情况」「视情况而定」——未说明判断规则时禁用。 + +「等」「等等」——用于省略必要枚举项时禁用。 + +### 3.5 空泛承诺与无依据结论 + +「确保用户满意」 + +「保证数据准确」 + +「避免所有错误」 + +「全面覆盖用户场景」 + +「系统会自动处理所有问题」 + +「用户能够轻松完成全部操作」 + +「该功能已经成熟稳定」 + +「该设计符合所有用户习惯」 + +以上表述只有在具备明确的验证依据、适用范围和判定标准时，才可以改写为具体的事实或约束。 + +### 3.6 不合格句式 + +「用户进入页面后，可以看到很多信息。」 + +「系统会根据情况进行相应处理。」 + +「用户点击按钮，然后系统就会完成操作。」 + +「如果有问题，系统会给出提示。」 + +「该功能主要用于提升用户体验。」 + +「支持多种输入方式，满足不同用户需求。」 + +「出现异常时，用户可以自行处理。」 + +「页面包含账号、内容、数据等相关模块。」 + +这些句式缺少具体对象、条件、行为、结果或处理规则，不得直接用于正式文档。 + +## 四、对错对照 +### 第 1 组：操作说明 + +不规范： 用户点一下提交按钮，然后就可以完成创建。 + +规范： 用户点击「提交」按钮后，系统校验表单必填项。校验通过时，系统创建记录并显示提交结果。 + +### 第 2 组：页面说明 + +不规范： 这里可以看到账号的各种信息，方便用户进行管理。 + +规范： 「账号列表」显示账号名称、所属平台、运营状态和最近更新时间。用户可通过列表操作入口查看账号详情。 + +### 第 3 组：输入规则 + +不规范： 用户填写相关信息就行，格式不对的话系统会提示。 + +规范： 用户必须填写「账号名称」字段。字段长度限制及允许字符范围为待确认。输入校验失败时的提示文案和恢复方式为待确认。 + +### 第 4 组：异常处理 + +不规范： 如果操作失败，系统会进行相应处理，用户重新试一下即可。 + +规范： 操作失败时，系统应显示失败原因和可执行的恢复操作。失败提示、重试条件及数据保留规则尚未确认。 + +### 第 5 组：功能价值 + +不规范： 该功能可以帮助运营人员高效地管理内容，提升工作效率。 + +规范： 「内容列表」集中显示内容标题、发布平台、审核状态和计划发布时间。运营人员可在列表中筛选内容，并进入详情页查看单条内容。 + +## 五、自检清单 + +每句话必须逐项检查。任一项不通过，必须修改后再提交。 + +语体检查： 是否存在聊天用语、口号、营销话术或主观评价？存在即不通过。 + +单义检查： 一个句子是否包含多个可独立执行的动作或多个独立结论？存在且未清晰拆分时不通过。 + +对象检查： 是否能明确指出句子描述的用户、系统、页面、控件、数据或业务对象？不能明确指出时不通过。 + +术语检查： 页面名、模块名、控件名和状态名是否与原型一致？不一致且未经说明时不通过。 + +来源检查： 是否出现没有来源、没有定义或未经确认的术语？存在且未标记时不通过。 + +动作检查： 是否明确写出发生了什么操作或系统行为？仅写「处理」「支持」「实现」而没有具体行为时不通过。 + +条件检查： 是否存在「如果」「当」「在……情况下」等条件表达，却没有说明对应结果？存在即不通过。 + +结果检查： 是否声称操作完成，却没有可观察的结果或完成标志？存在即不通过。 + +边界检查： 是否使用「多种」「部分」「适当」「相关」等词，却没有给出具体范围？存在即不通过。 + +事实检查： 是否将模拟行为、计划能力或未验证规则写成已实现事实？存在即不通过。 + +异常检查： 是否只写「提示用户」或「进行处理」，没有明确异常条件和恢复路径？存在即不通过。 + +独立阅读检查： 不查看原型的产品、开发和设计人员，是否能根据描述定位对象并理解行为？不能时不通过。 + +一致性检查： 同一对象在全文中是否存在多个未经定义的名称？存在即不通过。 + +精简检查： 删除某个词句后，事实、条件、动作或结果是否完全不受影响？若不受影响，应删除该词句。 + +## 六、最终验收规则 + +文档中的每句话都必须通过第五节自检。 + +所有界面名称必须有原型或已确认资料作为依据。 + +所有业务规则必须有明确来源；无来源的规则标记为「待确认」。 + +所有操作说明必须明确操作对象和可观察结果。 + +所有异常说明必须明确触发条件、反馈和恢复方式；尚未定义的内容标记为「待确认」。 + +禁用清单中的表达不得直接出现在正式说明正文中，必要的引用、规则举例和本规范自身的说明除外。 + +任何无法判断真假的描述均不得作为已确认事实写入文档。 + +文档以准确、可定位、可验证、可独立阅读为合格标准，不以篇幅或修辞作为质量标准。 diff --git a/product-planning/references/_留痕/stage-requirements-SKILL-20261016技能级assets前.md b/product-planning/references/_留痕/stage-requirements-SKILL-20261016技能级assets前.md new file mode 100644 index 0000000..ec4b514 --- /dev/null +++ b/product-planning/references/_留痕/stage-requirements-SKILL-20261016技能级assets前.md @@ -0,0 +1,198 @@ +--- +name: stage-requirements +description: 产品规划第②段，产品功能。只做一件事：把①段《使用场景》（`1e-使用场景.md`）细化成功能清单（做哪些 / 不做哪些 / 优先级），并钉死页面骨架（《界面布局》：有哪几页、每页几个板块、板块怎么排、跨页关系）。当用户要写②段两份、列产品功能、定优先级、梳理功能、定页面与板块布局，或说"只做产品功能"时调用。 +--- + +# ② 产品功能 + +回答「要做哪些产品功能、哪些明确不做、页面骨架怎么排」。产出两份： +`产品规划/prd/2a-产品功能.md`（功能清单）＋ `产品规划/prd/2b-界面布局.md`（页面骨架）。 + +> 段名与①「产品需求」构成 `产品需求 → 产品功能 → 界面交互 → 原型说明` 的对称链，四段各占一个词（产品 / 功能 / 界面 / 说明），无一词共用（2026-10-02 用户定）。旧名「需求与结构」「界面与交付」已废。 +> +> 与①段的分界：①回答「要解决什么问题、用户怎么用它」，②回答「要做哪些功能、长成什么骨架」。判据看文档主体 —— 主体是功能条目的有无与优先级、页面与板块骨架，归②；主体是问题、用户、取证与取舍理由，归①。 +> +> ⭐ 2026-10-06 用户定案：本段收窄为「只细化功能」。2026-10-07 用户定案「2 产品功能 和 界面布局不就是两个文档嘛」，两件事各成一份：产品功能（做什么）＋ 界面布局（长什么样）。（①段侧的定案原话与 grill 归属见 `stage-discovery`，本段不复述。） +> +> 本段就这两份：`产品规划/prd/2a-产品功能.md`（功能清单）＋ `产品规划/prd/2b-界面布局.md`（页面骨架）。 +> +> 别处的内容在本段怎么落地：状态流转与优先级都写进每条功能自己，不单独成文；用户故事取①段《使用场景》（`1e-使用场景.md`），本段按它推功能；grill / 压测在①段 1a（全场唯一一份 `grill-me`）；风险取①段《产品策略》的「假设与风险」。 +> +> （历史：本段收窄前的产出清单与其去向 → `_留痕/②段-已删除产出与方法论.md`） + +## ⭐⭐ ②—③ 交接口（唯一权威处 · 改边界只改这一块 · 2026-10-06 用户定案） + +> 🔴 「②段管什么、③段管什么」**只在本节定义一次**。本段其余章节、总入口 `product-planning/SKILL.md`、 +> `stage-discovery` 与 `stage-delivery` 的 `SKILL.md`、③段 `references/execution-runbook.md` 与 +> `references/layouts-tooling.md`，提到这条边界时一律**引用本节的行名**，⛔ 不许再复述清单。 +> 为什么立这一块：同型的复述病已经造成过真事故 —— 停线规则被三段写成「三种、②段写成「四种」， +> 两边长期漂着而没有任何门禁会报。单一可信源才拦得住。 +> 用户原话（本节的唯一出处，别处不再抄）：「3 是负责设计和交互，页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子」。 + +口径：②段钉骨架，③段做皮肉。 + +| 归②段（必须在本段定死） | 归③段（⛔ ②段不许写） | +|---|---| +| 有哪几页 | 配色 / 字体 / 间距 / 组件样式 / 动效 | +| 每页几个板块、板块怎么排 | 每个板块的视觉实现（怎么好看、怎么对齐、什么层次） | +| 跨页关系（怎么跳转） | 每个板块的交互行为（点哪、什么反馈、何时不可点） | +| 每页的主操作是什么 | 状态与空态的具体呈现 | +| 每条信息在哪一档承载（主屏常驻 / 可点入） | 响应式怎么变 | + +> ⭐ 骨架是判断基准，必须在②段定死。旧口径把「有哪几页」留在③段，结果就是③段做一版一个样，②段无从判断改得对不对。 +> ⛔ 交给③段时骨架是冻结的：③段不许新增 / 移动 / 删除板块，缺板块要回②段改。 +> 「归③段」那一列的六个词就是本段的**零视觉词红线**：本段其余章节与 `references/create-prd.md` 提到它时， +> 一律写成「见 §②—③ 交接口 的『归③段』列」，⛔ 不再逐处抄这六个词。 + +## 本段职责（2026-10-06 按「只细化功能」重划） + +本段回答一个问题：把①段的使用场景细化成哪些功能，这些功能长成一个什么骨架。拆成两问（原三问）： + +| 问 | 内容 | 落点 | +|---|---|---| +| 有哪些功能、优先级如何、什么不做 | 从每条使用场景推出功能条目；每条带优先级、状态流转、验收要点 | `2a-产品功能.md` | +| 这些功能长成什么骨架 | 有哪几页、每页几个板块、板块怎么排、跨页关系 | `2b-界面布局.md` | + +> ⭐ 本段产物的主体是功能条目的有无与优先级，这也是「产品功能」这个名字的依据。实测本项目 **24 条**功能定义（`F001`–`F024`）**落在④段产品文档**，②段 `prd/` 为空 —— 「功能落在哪段」按实际记，⛔ 不要拿本段的定位当既成事实写。 +> ⛔ 本段不许重开需求：需求澄清、grill 反问、取证都在①段做完了。本段假定需求已成立，只做功能取舍。 +> ⭐ 功能按使用场景组织（2026-10-06 用户定案），一条使用场景下可能放跨多个页面的功能。用户原话：「功能可以分使用场景梳理（可能是跨页面的）」。不按页面组织 —— 按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上。 + +## 2a 产品功能 + +| 子步 | 读 | 产出 | +|---|---|---| +| 2a 产品功能 | `references/create-prd.md` | `产品规划/prd/2a-产品功能.md` | + +回答：要做哪些功能、哪些明确不做、每条什么优先级、每个功能自身怎么流转。 + +⭐ **起手先复制模板**（2026-10-16 补）：`assets/产品规划模板.md` 的「一、功能清单」那张 12 列表 —— 表头与顺序照抄，把 `<尖括号>` 占位换成真实内容，⛔ 不要从空白页重写结构；**目标产品特有列**（本项目＝租户列）目标产品真有才追加，写法见该模板「列口径」末行。 + +## 2b 界面布局 + +| 子步 | 读 | 产出 | +|---|---|---| +| 2b 界面布局 | `assets/diagram-design/SKILL.md`（第三方 skill 整树保留，其 `references/`、`scripts/`、`assets/` 路径均相对该目录解析） | `产品规划/prd/2b-界面布局.md` | + +回答：有哪几页、每页几个板块、板块怎么排、跨页关系怎么跳。 + +⭐ **起手先复制模板**（2026-10-16 补）：`assets/产品规划模板.md` 的「二、页面骨架」那张 8 列表 —— 表头与顺序照抄，把 `<尖括号>` 占位换成真实内容，⛔ 不要从空白页重写结构。 + +> 顺序是 2a → 2b：布局是功能清单的空间展开，功能还没定就画布局等于凭空发明版面。 +> ⛔ 2a 之前不再需要压测步骤，压测已前移①段 1a 的 B 节。 + +### 功能清单怎么组织（逐条可核） + +每个功能条目必须带齐这几样： + +| 字段 | 写什么 | 判据 | +|---|---|---| +| 功能名 | 一句话说清做什么（动词开头的用户语言） | ⛔ 不写实现名 | +| 来自哪条场景 | 追回①段《使用场景》（`产品规划/research/1e-使用场景.md`）的编号 | ⛔ 追不回的条目该砍 | +| 优先级 | P0 / P1 / P2 | 见下方「优先级」 | +| 状态流转 | 这个功能自身有哪几个状态、怎么迁移（不适用就写「无状态」） | ⛔ 不许省成空白 | +| 验收要点 | 怎么算做完（可观察） | ⛔ 不写「体验好」这类 | +| 跨哪些页面 | 这个功能在骨架的哪几页上发生 | 可为多页 | + +🔴 **输入缺失时怎么办（②段唯一分支，2026-10-16 补）**：「来自哪条场景」这一列的输入是①段《使用场景》；它缺失时（`1e-使用场景.md` 不存在，或①段收口时把它列进了豁免清单）⇒ **退化为追回 `1a` 决策表**： + +1. 到 `产品规划/research/1a-需求文档.md` 的决策表里逐条认领（A 节「问题与边界」／B 节「形态与状态」），把这一列改标成「来自 `1a-需求文档.md` §<节号>-<条目>」。 +2. 两条都追不到（`1e` 与 `1a` 都没有对应条目）⇒ 该功能条目**砍掉**，并写明「无需求来源，已砍」。 + +⛔ 不许因为上游缺文件就把这一列放空或写「未定」—— 那样「功能该不该有」就没有判据了。 +⛔ 也不许反过来：`1e` 与 `1a` 都在时，一律以 `1e` 为准，退化只在**缺失**时启用。 + +优先级（⛔ 不许凭空打分，见硬约束）： +- P0：不做则①段某条使用场景整条办不成 +- P1：不做则场景能办成但要多绕（本可用一次点击，变成三步） +- P2：不做不影响场景办成，只是更好用 + +> 优先级判据 = 一句可复述的话。本项目没有数据源，不填数字。 + +### 2b 界面布局怎么写 + +本份专管界面骨架，⛔ 不写功能条目的有无与优先级（那是 `2a-产品功能.md`）。一句话分工：`2a` 管「做哪些事」，`2b` 管「这些事落在哪几页、每页长什么结构」。 + +🔴 **骨架怎么来（2026-10-16 补）**：现读**目标产品整页快照**再挑板块 —— 路径与③段同源：`references/stage-delivery/assets/design-systems/<选定套>/assets/component-library/snapshot/<板块>.html`。②段从快照的板块集里**挑**（挑哪几块、怎么排），③段按挑好的骨架**做**；板块名一律照抄快照，⛔ 不许自造（第 1 轮返工的病根就是自造 `nav-item` × 21）。本项目真正用到的快照是 `snapshot/script.html`：选不到对应板块时，写明用的是哪一份快照、为什么。 + +| 问 | 回答 | 内容 | +|---|---|---| +| 页面关系 | 有哪几页、门开在哪、**新功能放在已有产品的哪一页** | 页面清单、页面流转、导航、**已有产品的页面 ＋ 新增块** | +| 页面内布局 | 房间里家具怎么摆 | 每页的板块清单 ＋ 排列顺序（wireframe 灰块粒度） | + +> ⭐ 拆成两份是 2026-10-07 的用户定案。旧写法一份装两半，同一件事要写两遍（比如 `header / side / footer` 既像页面框架又像页内板块）；拆开后各自只写自己那一侧，正好逼着把边界写明确。 +> 🔴 防重写规则（拆开后必须守）：页面级框架（`header / side / footer`）只在 `2b` 写一次；`2a` 的功能条目里只许出现「跨哪些页面」，⛔ 不许描述页面长什么样。 +> ⚠️ 粒度：本段给灰块框图（有哪些块、什么顺序），⛔ 不给视觉（颜色、字体、间距、圆角、层次）。视觉类六词（见 §②—③ 交接口 的『归③段』列），本段（含布局）仍不许写。 +> ⚠️ 旧 `ux/diagrams/system-architecture.html` 画的是系统组件之间的关系，属实现视角，已改名。本段要的是页面与板块，属产品视角，⛔ 不许再叫「系统架构」。 + +## 硬约束 +- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。 + +- ⭐ 本段不是压测入口（2026-10-06）：`grill-me` 全场只有①段一份，火力点已扩到覆盖「做成什么样、状态怎么流转」。⛔ 本段不许再开一轮反问 —— ①段 `1a-需求文档.md` 的决策表就是本段的压测输入。用户始终不回应时①段怎么处理，本段照旧继承，但不再自己去问。 +- ⭐ 假设照旧继承，但账在①段：`1a-需求文档.md` 带进来的每条 `【假设】`，在②段落盘时逐条给结论，只允许三种归宿 —— 已确认（写明确认人与时间）｜待实现且已排定确认时机（写明「在第几步落地前必须问」）｜`【已按假设落地】`（写清影响面 + 回退口径）。⛔ 第四种（既未确认、已进实现、又无落地说明）不许带进本段。 + - ⭐ 引用假设必须带状态：本段任何一条功能 / 状态流转 / 分档，只要依据是某条假设，就在括号里带上该假设的当前状态（`（依据 Q7 · 已确认）`、`（依据 Q10 · 【已按假设落地 · 影响面：每版全量复制 → 版本目录体积】）`）。下游③段据此判断这条能不能当硬约束用。 + - ⭐ 假设与实测要回头对账：凡靠假设得出的结论，一旦下游跑出实测结果，必须回填并改状态。实测踩坑：`PRD.md:132` 假设 3「单文件 HTML 在 `file://` 下能双击打开（③段需实测）」标着待实测，而③段早已实测了 16 版，事实成立却没人回填。 +- ⭐ 待确认 / 暂缓项必须带回收三字段（2026-10-02）：本段任何「待确认 / 暂缓 / 待定」条目必须同时写 复核人 ＋ 复核时机 ＋ 结论落点（哪个文件哪一节），三字段缺一不许落盘。⛔ 只写「暂缓」等于无限期搁置。 +- 「不做 / 移出」必须逐条核对，不许自行裁剪：写②段前、落盘后各做一次 —— 把②段里每一条「不做 / 移出 / 暂缓」与 `1a-需求文档.md` 的已拍板项逐条对照。凡涉及已拍板项，一律不得自行裁剪或改口径，必须列成「与已定决策的差异」表（原条目 / 原口径 / 拟改口径 / 理由）交用户显式确认。只写「已核对无冲突」不算核对，要给出对照过的条目数。 +- ⭐ 每条功能必须能追回①段《使用场景》（`1e-使用场景.md`）：追不回的功能就要么补一条场景、要么砍掉。这是本段唯一的功能有无判据，代替凭空打分。 +- ⭐ 状态流转写在功能条目里，⛔ 不再单独成文（2026-10-06）：每个功能条目自带「状态流转」字段。六项治理照旧全覆盖（失败恢复路径、持久化范围、并发冲突、幂等、超时迁移目标、不可逆操作二次确认），只是落点从独立文档移进功能条目。 + - ⭐ 状态放不到任何功能上的中间态，要么删掉，要么补一个功能条目让它服务。 +- ⭐ 骨架必须给全（2026-10-06）：②段的《界面布局》必须给全 §②—③ 交接口 的「归②段」列那几样，逐条对应。⛔ 缺任何一样，③段就没有方向。 + - 信息承载分档的判据：「删掉它，主操作还做得成吗」—— 答「做得成」就只能进「可点入」。⛔ 「能读到」= 可点入，不等于主屏常驻；不许以「②段要求能读到」为由把信息留在主屏。 +- ⛔ 本段（含布局）不许写视觉（六词清单见 §②—③ 交接口 的『归③段』列），一个字都不许出现。 +- ⭐ 文档前面必须配图（2026-10-15 用户令）：本段落盘的每份文档，正文（第一张表 / 第一小节）之前必须先给一张图 —— 本段画《页面与功能结构图》；用 `diagram-design` 画，⛔ 手写 Mermaid。图是正文内容，⛔ 不写成标题旁边或标题下面的注解小字。 +- 段内不反问，做完直接往下走。停线规则（哪几种情况停、怎么判）见 `product-planning` 的「执行规则」—— ⛔ 本段不复述，免得两处漂。 +- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。 + +## 完成标准 + +- `2a-产品功能.md` 与 `2b-界面布局.md` 两份都在，且只有这两份（⛔ 不许再产出 `grill-decisions` / `user-stories` / `priorities` / `pre-mortem` / `state-machine` / `diagrams` 六份中的任何一份；⛔ 也不许再退回单份 `PRD.md`） +- ②段的「不做 / 移出」清单逐条对照过①段已拍板项，差异行为 0 或每一行都已获用户显式确认（附对照条目数，不得只写「无冲突」） +- 功能清单每条带齐「功能名 / 来自哪条场景 / 优先级 / 状态流转 / 验收要点 / 跨哪些页面」六字段；⛔ 追不回①段场景的条目为 0 +- 状态流转六项治理全覆盖（失败恢复 / 持久化 / 并发 / 幂等 / 超时 / 不可逆二次确认），且落在功能条目内 +- 《界面布局》给全 §②—③ 交接口 的「归②段」列（含分档判据回答） +- ⛔ 全文零视觉词（六词清单见 §②—③ 交接口 的『归③段』列） +- 每条假设都有归宿（三选一，无第四种）；凡依据假设的功能 / 状态流转 / 分档，条目里都带上了假设状态标注 +- ⭐ 2a 与 2b 两份前面都配了图（用 `diagram-design`，⛔ 无手写 Mermaid） +- 本段所有「待确认 / 暂缓」条目都带齐 复核人 / 复核时机 / 结论落点 三字段 +- ⭐ 两份都过了「说人话」内容准则（源技能、判据与门槛见 `product-planning` 的「执行规则」内容准则条）；段末报告须写明「已过内容准则，评分 X/50」 + +### 六条可机核项（2026-10-16 补 · 逐条给读数，⛔ 不许只写「已核对」） + +| # | 判据 | 怎么核 | +|---|---|---| +| 1 | **页面清单条数 ＝ 原型 `.html` 文件数** | 数 `2b` 的「页面名」列行数，与 `产品原型/pages/*.html` 里**原型页**的个数比对（⛔ 产品文档、`3c-*`、`3d-*` 不算原型页） | +| 2 | **既有页沿用的板块名 ∈ 目标产品整页快照的板块集；新增页的功能区名允许自定、但须写明依据** | 拿 `2b` 的「板块清单」列逐名去 `snapshot/<板块>.html` 里 grep：**快照里有的**必须逐字命中；**只在新增页出现的**允许自定，该行须写明「新增页 · 依据」（照 §骨架怎么来 的活口）；⛔ 给既有页自造假块名一律报红 | +| 3 | **功能条目数 ＝ ④段产品文档的 F 条数，且 F 编号唯一连续** | 数 `2a` 的 F 行数，与成品〈三、功能清单〉的 F 条数比对；再验 `F001…F00N` 无跳号无重号 | +| 4 | **每条 F 带齐**：场景编号（或退化后的 `1a` 条目）／优先级／状态流转／验收要点 | 逐行查四列非空；⛔「未定」「暂缓」不算已填 | +| 5 | **2a 的页面名／功能区在 2b 全追得到；2b 挂的 F 在 2a 全追得到** | 两个差集都要为空，读数写「正向 N 条全中／反向 M 条全中」 | +| 6 | **全文零视觉词**（清单见 §②—③ 交接口 的『归③段』列） | 逐词 grep 两份产物，命中数须为 0 | + +## 反面清单 + +- ⛔ 在本段重开一轮 grill 反问（2026-10-06）：反问已整套前移①段 1a，本段只细化功能 +- ⛔ 产出本段两份之外的文档（本段只 `2a` 与 `2b`，白名单由 `check_naming.py` 机器判） +- ⛔ 把「产品功能」与「界面布局」又塞回一份（2026-10-07 用户定案：这就是两个文档） +- ⛔ `2a` 里描述页面结构 / `2b` 里写功能条目的有无与优先级（越界即重写） +- ⛔ 按页面组织功能清单（2026-10-06）：功能要按使用场景组织，一条场景可跨多页；按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上 +- ⛔ 凭空给功能打分（Importance × Satisfaction / ICE / RICE）：没有数据源。优先级只能是 P0/P1/P2 + 一句可复述的判据 +- ⛔ 功能条目追不回①段《使用场景》（`1e-使用场景.md`）：追不回就要么补场景、要么砍条目 +- 用「移出第一版 / 不做」自行砍掉已拍板项，或只声称「已核对无冲突」却不列对照条目数 +- 在本段重开需求验证（该做取证与需求定义的是①段；本段假定需求已成立，只做功能取舍） +- ⛔ 骨架给不全（2026-10-06）：只给页面清单、不给每页板块与排列，或只给布局、不给跨页关系 —— ③段拿不到方向，就会一版一个样 +- ⛔ 把某条信息标为「主屏常驻」却答不上「缺了主操作就做不成事」：按判据应归「可点入」 +- 状态流转只画正常路径，不管失败与并发；或状态放不到任何功能条目上（凭空中间态） +- ⛔ 在本段写视觉（清单见 §②—③ 交接口）—— 那是③段 +- 越界去出原型或写说明文档（那是第③④段） +- 把 `【假设】` 原样带进②段当既定事实；或假设已被实现却从不回填状态 +- 只写「暂缓」而不给复核人 / 复核时机 / 结论落点 —— 等于让这条永远放着 +- ⛔ 两份没过「说人话」内容准则就落盘 —— 口径与门槛见 `product-planning` 的「执行规则」内容准则条 +- ⛔ 改本技能包的规则文件、却不过「说人话」这一关（2026-10-07）：规则和产出同一把尺子 —— 口径见 `product-planning` 的「执行规则」内容准则条 + +## 本段读什么、守什么 + +- 方法论两份：`references/create-prd.md`（功能清单）、`references/state-machine.md`（六项治理清单仍要读，落点变成功能条目内）。 +- 产物模板：`assets/产品规划模板.md`（两张表的表头与顺序的**唯一定义处**；2a／2b 起手都从它复制）。 +- 绘图资产：`assets/diagram-design/`（整树保留，供画布局图）。 +- 贯穿纪律：同一件事只写一遍 —— 同一批人 / 同一批场景若在①②两段各写一份，必然打架。 + +📎 本段收窄前的产出清单与其去向（含方法论去留）见 `_留痕/②段-已删除产出与方法论.md` —— 正文不展开；防复活由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` / `WHITELIST` 机器判。 diff --git a/product-planning/references/_留痕/stage-requirements/SKILL.md b/product-planning/references/_留痕/stage-requirements/SKILL.md new file mode 100644 index 0000000..9cf0586 --- /dev/null +++ b/product-planning/references/_留痕/stage-requirements/SKILL.md @@ -0,0 +1,198 @@ +--- +name: stage-requirements +description: 产品规划第②段，产品功能。只做一件事：把①段《使用场景》（`1e-使用场景.md`）细化成功能清单（做哪些 / 不做哪些 / 优先级），并钉死页面骨架（《界面布局》：有哪几页、每页几个板块、板块怎么排、跨页关系）。当用户要写②段两份、列产品功能、定优先级、梳理功能、定页面与板块布局，或说"只做产品功能"时调用。 +--- + +# ② 产品功能 + +回答「要做哪些产品功能、哪些明确不做、页面骨架怎么排」。产出两份： +`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单）＋ `docs/pm/<项目>/prd/2b-界面布局.md`（页面骨架）。 + +> 段名与①「产品需求」构成 `产品需求 → 产品功能 → 界面交互 → 原型说明` 的对称链，四段各占一个词（产品 / 功能 / 界面 / 说明），无一词共用（2026-10-02 用户定）。旧名「需求与结构」「界面与交付」已废。 +> +> 与①段的分界：①回答「要解决什么问题、用户怎么用它」，②回答「要做哪些功能、长成什么骨架」。判据看文档主体 —— 主体是功能条目的有无与优先级、页面与板块骨架，归②；主体是问题、用户、取证与取舍理由，归①。 +> +> ⭐ 2026-10-06 用户定案：本段收窄为「只细化功能」。2026-10-07 用户定案「2 产品功能 和 界面布局不就是两个文档嘛」，两件事各成一份：产品功能（做什么）＋ 界面布局（长什么样）。（①段侧的定案原话与 grill 归属见 `stage-discovery`，本段不复述。） +> +> 本段就这两份：`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单）＋ `docs/pm/<项目>/prd/2b-界面布局.md`（页面骨架）。 +> +> 别处的内容在本段怎么落地：状态流转与优先级都写进每条功能自己，不单独成文；用户故事取①段《使用场景》（`1e-使用场景.md`），本段按它推功能；grill / 压测在①段 1a（全场唯一一份 `grill-me`）；风险取①段《产品策略》的「假设与风险」。 +> +> （历史：本段收窄前的产出清单与其去向 → `_留痕/②段-已删除产出与方法论.md`） + +## ⭐⭐ ②—③ 交接口（唯一权威处 · 改边界只改这一块 · 2026-10-06 用户定案） + +> 🔴 「②段管什么、③段管什么」**只在本节定义一次**。本段其余章节、总入口 `product-planning/SKILL.md`、 +> `stage-discovery` 与 `stage-delivery` 的 `SKILL.md`、③段 `references/execution-runbook.md` 与 +> `references/layouts-tooling.md`，提到这条边界时一律**引用本节的行名**，⛔ 不许再复述清单。 +> 为什么立这一块：同型的复述病已经造成过真事故 —— 停线规则被三段写成「三种、②段写成「四种」， +> 两边长期漂着而没有任何门禁会报。单一可信源才拦得住。 +> 用户原话（本节的唯一出处，别处不再抄）：「3 是负责设计和交互，页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子」。 + +口径：②段钉骨架，③段做皮肉。 + +| 归②段（必须在本段定死） | 归③段（⛔ ②段不许写） | +|---|---| +| 有哪几页 | 配色 / 字体 / 间距 / 组件样式 / 动效 | +| 每页几个板块、板块怎么排 | 每个板块的视觉实现（怎么好看、怎么对齐、什么层次） | +| 跨页关系（怎么跳转） | 每个板块的交互行为（点哪、什么反馈、何时不可点） | +| 每页的主操作是什么 | 状态与空态的具体呈现 | +| 每条信息在哪一档承载（主屏常驻 / 可点入） | 响应式怎么变 | + +> ⭐ 骨架是判断基准，必须在②段定死。旧口径把「有哪几页」留在③段，结果就是③段做一版一个样，②段无从判断改得对不对。 +> ⛔ 交给③段时骨架是冻结的：③段不许新增 / 移动 / 删除板块，缺板块要回②段改。 +> 「归③段」那一列的六个词就是本段的**零视觉词红线**：本段其余章节与 `references/create-prd.md` 提到它时， +> 一律写成「见 §②—③ 交接口 的『归③段』列」，⛔ 不再逐处抄这六个词。 + +## 本段职责（2026-10-06 按「只细化功能」重划） + +本段回答一个问题：把①段的使用场景细化成哪些功能，这些功能长成一个什么骨架。拆成两问（原三问）： + +| 问 | 内容 | 落点 | +|---|---|---| +| 有哪些功能、优先级如何、什么不做 | 从每条使用场景推出功能条目；每条带优先级、状态流转、验收要点 | `2a-产品功能.md` | +| 这些功能长成什么骨架 | 有哪几页、每页几个板块、板块怎么排、跨页关系 | `2b-界面布局.md` | + +> ⭐ 本段产物的主体是功能条目的有无与优先级，这也是「产品功能」这个名字的依据。实测本项目 **24 条**功能定义（`F001`–`F024`）**落在④段产品文档**，②段 `prd/` 为空 —— 「功能落在哪段」按实际记，⛔ 不要拿本段的定位当既成事实写。 +> ⛔ 本段不许重开需求：需求澄清、grill 反问、取证都在①段做完了。本段假定需求已成立，只做功能取舍。 +> ⭐ 功能按使用场景组织（2026-10-06 用户定案），一条使用场景下可能放跨多个页面的功能。用户原话：「功能可以分使用场景梳理（可能是跨页面的）」。不按页面组织 —— 按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上。 + +## 2a 产品功能 + +| 子步 | 读 | 产出 | +|---|---|---| +| 2a 产品功能 | `references/create-prd.md` | `docs/pm/<项目>/prd/2a-产品功能.md` | + +回答：要做哪些功能、哪些明确不做、每条什么优先级、每个功能自身怎么流转。 + +⭐ **起手先复制模板**（2026-10-16 补）：`assets/产品规划模板.md` 的「一、功能清单」那张 12 列表 —— 表头与顺序照抄，把 `<尖括号>` 占位换成真实内容，⛔ 不要从空白页重写结构。 + +## 2b 界面布局 + +| 子步 | 读 | 产出 | +|---|---|---| +| 2b 界面布局 | `assets/diagram-design/SKILL.md`（第三方 skill 整树保留，其 `references/`、`scripts/`、`assets/` 路径均相对该目录解析） | `docs/pm/<项目>/prd/2b-界面布局.md` | + +回答：有哪几页、每页几个板块、板块怎么排、跨页关系怎么跳。 + +⭐ **起手先复制模板**（2026-10-16 补）：`assets/产品规划模板.md` 的「二、页面骨架」那张 8 列表 —— 表头与顺序照抄，把 `<尖括号>` 占位换成真实内容，⛔ 不要从空白页重写结构。 + +> 顺序是 2a → 2b：布局是功能清单的空间展开，功能还没定就画布局等于凭空发明版面。 +> ⛔ 2a 之前不再需要压测步骤，压测已前移①段 1a 的 B 节。 + +### 功能清单怎么组织（逐条可核） + +每个功能条目必须带齐这几样： + +| 字段 | 写什么 | 判据 | +|---|---|---| +| 功能名 | 一句话说清做什么（动词开头的用户语言） | ⛔ 不写实现名 | +| 来自哪条场景 | 追回①段《使用场景》（`docs/pm/<项目>/research/1e-使用场景.md`）的编号 | ⛔ 追不回的条目该砍 | +| 优先级 | P0 / P1 / P2 | 见下方「优先级」 | +| 状态流转 | 这个功能自身有哪几个状态、怎么迁移（不适用就写「无状态」） | ⛔ 不许省成空白 | +| 验收要点 | 怎么算做完（可观察） | ⛔ 不写「体验好」这类 | +| 跨哪些页面 | 这个功能在骨架的哪几页上发生 | 可为多页 | + +🔴 **输入缺失时怎么办（②段唯一分支，2026-10-16 补）**：「来自哪条场景」这一列的输入是①段《使用场景》；它缺失时（`1e-使用场景.md` 不存在，或①段收口时把它列进了豁免清单）⇒ **退化为追回 `1a` 决策表**： + +1. 到 `docs/pm/<项目>/research/1a-需求文档.md` 的决策表里逐条认领（A 节「问题与边界」／B 节「形态与状态」），把这一列改标成「来自 `1a-需求文档.md` §<节号>-<条目>」。 +2. 两条都追不到（`1e` 与 `1a` 都没有对应条目）⇒ 该功能条目**砍掉**，并写明「无需求来源，已砍」。 + +⛔ 不许因为上游缺文件就把这一列放空或写「未定」—— 那样「功能该不该有」就没有判据了。 +⛔ 也不许反过来：`1e` 与 `1a` 都在时，一律以 `1e` 为准，退化只在**缺失**时启用。 + +优先级（⛔ 不许凭空打分，见硬约束）： +- P0：不做则①段某条使用场景整条办不成 +- P1：不做则场景能办成但要多绕（本可用一次点击，变成三步） +- P2：不做不影响场景办成，只是更好用 + +> 优先级判据 = 一句可复述的话。本项目没有数据源，不填数字。 + +### 2b 界面布局怎么写 + +本份专管界面骨架，⛔ 不写功能条目的有无与优先级（那是 `2a-产品功能.md`）。一句话分工：`2a` 管「做哪些事」，`2b` 管「这些事落在哪几页、每页长什么结构」。 + +🔴 **骨架怎么来（2026-10-16 补）**：现读**目标产品整页快照**再挑板块 —— 路径与③段同源：`references/stage-delivery/assets/design-systems/<选定套>/assets/component-library/snapshot/<板块>.html`。②段从快照的板块集里**挑**（挑哪几块、怎么排），③段按挑好的骨架**做**；板块名一律照抄快照，⛔ 不许自造（第 1 轮返工的病根就是自造 `nav-item` × 21）。本项目真正用到的快照是 `snapshot/script.html`：选不到对应板块时，写明用的是哪一份快照、为什么。 + +| 问 | 回答 | 内容 | +|---|---|---| +| 页面关系 | 有哪几页、门开在哪、**新功能放在已有产品的哪一页** | 页面清单、页面流转、导航、**已有产品的页面 ＋ 新增块** | +| 页面内布局 | 房间里家具怎么摆 | 每页的板块清单 ＋ 排列顺序（wireframe 灰块粒度） | + +> ⭐ 拆成两份是 2026-10-07 的用户定案。旧写法一份装两半，同一件事要写两遍（比如 `header / side / footer` 既像页面框架又像页内板块）；拆开后各自只写自己那一侧，正好逼着把边界写明确。 +> 🔴 防重写规则（拆开后必须守）：页面级框架（`header / side / footer`）只在 `2b` 写一次；`2a` 的功能条目里只许出现「跨哪些页面」，⛔ 不许描述页面长什么样。 +> ⚠️ 粒度：本段给灰块框图（有哪些块、什么顺序），⛔ 不给视觉（颜色、字体、间距、圆角、层次）。视觉类六词（见 §②—③ 交接口 的『归③段』列），本段（含布局）仍不许写。 +> ⚠️ 旧 `ux/diagrams/system-architecture.html` 画的是系统组件之间的关系，属实现视角，已改名。本段要的是页面与板块，属产品视角，⛔ 不许再叫「系统架构」。 + +## 硬约束 +- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。 + +- ⭐ 本段不是压测入口（2026-10-06）：`grill-me` 全场只有①段一份，火力点已扩到覆盖「做成什么样、状态怎么流转」。⛔ 本段不许再开一轮反问 —— ①段 `1a-需求文档.md` 的决策表就是本段的压测输入。用户始终不回应时①段怎么处理，本段照旧继承，但不再自己去问。 +- ⭐ 假设照旧继承，但账在①段：`1a-需求文档.md` 带进来的每条 `【假设】`，在②段落盘时逐条给结论，只允许三种归宿 —— 已确认（写明确认人与时间）｜待实现且已排定确认时机（写明「在第几步落地前必须问」）｜`【已按假设落地】`（写清影响面 + 回退口径）。⛔ 第四种（既未确认、已进实现、又无落地说明）不许带进本段。 + - ⭐ 引用假设必须带状态：本段任何一条功能 / 状态流转 / 分档，只要依据是某条假设，就在括号里带上该假设的当前状态（`（依据 Q7 · 已确认）`、`（依据 Q10 · 【已按假设落地 · 影响面：每版全量复制 → 版本目录体积】）`）。下游③段据此判断这条能不能当硬约束用。 + - ⭐ 假设与实测要回头对账：凡靠假设得出的结论，一旦下游跑出实测结果，必须回填并改状态。实测踩坑：`PRD.md:132` 假设 3「单文件 HTML 在 `file://` 下能双击打开（③段需实测）」标着待实测，而③段早已实测了 16 版，事实成立却没人回填。 +- ⭐ 待确认 / 暂缓项必须带回收三字段（2026-10-02）：本段任何「待确认 / 暂缓 / 待定」条目必须同时写 复核人 ＋ 复核时机 ＋ 结论落点（哪个文件哪一节），三字段缺一不许落盘。⛔ 只写「暂缓」等于无限期搁置。 +- 「不做 / 移出」必须逐条核对，不许自行裁剪：写②段前、落盘后各做一次 —— 把②段里每一条「不做 / 移出 / 暂缓」与 `1a-需求文档.md` 的已拍板项逐条对照。凡涉及已拍板项，一律不得自行裁剪或改口径，必须列成「与已定决策的差异」表（原条目 / 原口径 / 拟改口径 / 理由）交用户显式确认。只写「已核对无冲突」不算核对，要给出对照过的条目数。 +- ⭐ 每条功能必须能追回①段《使用场景》（`1e-使用场景.md`）：追不回的功能就要么补一条场景、要么砍掉。这是本段唯一的功能有无判据，代替凭空打分。 +- ⭐ 状态流转写在功能条目里，⛔ 不再单独成文（2026-10-06）：每个功能条目自带「状态流转」字段。六项治理照旧全覆盖（失败恢复路径、持久化范围、并发冲突、幂等、超时迁移目标、不可逆操作二次确认），只是落点从独立文档移进功能条目。 + - ⭐ 状态放不到任何功能上的中间态，要么删掉，要么补一个功能条目让它服务。 +- ⭐ 骨架必须给全（2026-10-06）：②段的《界面布局》必须给全 §②—③ 交接口 的「归②段」列那几样，逐条对应。⛔ 缺任何一样，③段就没有方向。 + - 信息承载分档的判据：「删掉它，主操作还做得成吗」—— 答「做得成」就只能进「可点入」。⛔ 「能读到」= 可点入，不等于主屏常驻；不许以「②段要求能读到」为由把信息留在主屏。 +- ⛔ 本段（含布局）不许写视觉（六词清单见 §②—③ 交接口 的『归③段』列），一个字都不许出现。 +- ⭐ 文档前面必须配图（2026-10-15 用户令）：本段落盘的每份文档，正文（第一张表 / 第一小节）之前必须先给一张图 —— 本段画《页面与功能结构图》；用 `diagram-design` 画，⛔ 手写 Mermaid。图是正文内容，⛔ 不写成标题旁边或标题下面的注解小字。 +- 段内不反问，做完直接往下走。停线规则（哪几种情况停、怎么判）见 `product-planning` 的「执行规则」—— ⛔ 本段不复述，免得两处漂。 +- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。 + +## 完成标准 + +- `2a-产品功能.md` 与 `2b-界面布局.md` 两份都在，且只有这两份（⛔ 不许再产出 `grill-decisions` / `user-stories` / `priorities` / `pre-mortem` / `state-machine` / `diagrams` 六份中的任何一份；⛔ 也不许再退回单份 `PRD.md`） +- ②段的「不做 / 移出」清单逐条对照过①段已拍板项，差异行为 0 或每一行都已获用户显式确认（附对照条目数，不得只写「无冲突」） +- 功能清单每条带齐「功能名 / 来自哪条场景 / 优先级 / 状态流转 / 验收要点 / 跨哪些页面」六字段；⛔ 追不回①段场景的条目为 0 +- 状态流转六项治理全覆盖（失败恢复 / 持久化 / 并发 / 幂等 / 超时 / 不可逆二次确认），且落在功能条目内 +- 《界面布局》给全 §②—③ 交接口 的「归②段」列（含分档判据回答） +- ⛔ 全文零视觉词（六词清单见 §②—③ 交接口 的『归③段』列） +- 每条假设都有归宿（三选一，无第四种）；凡依据假设的功能 / 状态流转 / 分档，条目里都带上了假设状态标注 +- ⭐ 2a 与 2b 两份前面都配了图（用 `diagram-design`，⛔ 无手写 Mermaid） +- 本段所有「待确认 / 暂缓」条目都带齐 复核人 / 复核时机 / 结论落点 三字段 +- ⭐ 两份都过了「说人话」内容准则（源技能、判据与门槛见 `product-planning` 的「执行规则」内容准则条）；段末报告须写明「已过内容准则，评分 X/50」 + +### 六条可机核项（2026-10-16 补 · 逐条给读数，⛔ 不许只写「已核对」） + +| # | 判据 | 怎么核 | +|---|---|---| +| 1 | **页面清单条数 ＝ 原型 `.html` 文件数** | 数 `2b` 的「页面名」列行数，与 `designs/<项目>/*.html` 里**原型页**的个数比对（⛔ 产品文档、`3c-*`、`3d-*` 不算原型页） | +| 2 | **每个板块名 ∈ 目标产品整页快照的板块集** | 拿 `2b` 的「板块清单」列逐名去 `snapshot/<板块>.html` 里 grep；⛔ 自造名一律报红 | +| 3 | **功能条目数 ＝ ④段产品文档的 F 条数，且 F 编号唯一连续** | 数 `2a` 的 F 行数，与成品〈三、功能清单〉的 F 条数比对；再验 `F001…F00N` 无跳号无重号 | +| 4 | **每条 F 带齐**：场景编号（或退化后的 `1a` 条目）／优先级／状态流转／验收要点 | 逐行查四列非空；⛔「未定」「暂缓」不算已填 | +| 5 | **2a 的页面名／功能区在 2b 全追得到；2b 挂的 F 在 2a 全追得到** | 两个差集都要为空，读数写「正向 N 条全中／反向 M 条全中」 | +| 6 | **全文零视觉词**（清单见 §②—③ 交接口 的『归③段』列） | 逐词 grep 两份产物，命中数须为 0 | + +## 反面清单 + +- ⛔ 在本段重开一轮 grill 反问（2026-10-06）：反问已整套前移①段 1a，本段只细化功能 +- ⛔ 产出本段两份之外的文档（本段只 `2a` 与 `2b`，白名单由 `check_naming.py` 机器判） +- ⛔ 把「产品功能」与「界面布局」又塞回一份（2026-10-07 用户定案：这就是两个文档） +- ⛔ `2a` 里描述页面结构 / `2b` 里写功能条目的有无与优先级（越界即重写） +- ⛔ 按页面组织功能清单（2026-10-06）：功能要按使用场景组织，一条场景可跨多页；按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上 +- ⛔ 凭空给功能打分（Importance × Satisfaction / ICE / RICE）：没有数据源。优先级只能是 P0/P1/P2 + 一句可复述的判据 +- ⛔ 功能条目追不回①段《使用场景》（`1e-使用场景.md`）：追不回就要么补场景、要么砍条目 +- 用「移出第一版 / 不做」自行砍掉已拍板项，或只声称「已核对无冲突」却不列对照条目数 +- 在本段重开需求验证（该做取证与需求定义的是①段；本段假定需求已成立，只做功能取舍） +- ⛔ 骨架给不全（2026-10-06）：只给页面清单、不给每页板块与排列，或只给布局、不给跨页关系 —— ③段拿不到方向，就会一版一个样 +- ⛔ 把某条信息标为「主屏常驻」却答不上「缺了主操作就做不成事」：按判据应归「可点入」 +- 状态流转只画正常路径，不管失败与并发；或状态放不到任何功能条目上（凭空中间态） +- ⛔ 在本段写视觉（清单见 §②—③ 交接口）—— 那是③段 +- 越界去出原型或写说明文档（那是第③④段） +- 把 `【假设】` 原样带进②段当既定事实；或假设已被实现却从不回填状态 +- 只写「暂缓」而不给复核人 / 复核时机 / 结论落点 —— 等于让这条永远放着 +- ⛔ 两份没过「说人话」内容准则就落盘 —— 口径与门槛见 `product-planning` 的「执行规则」内容准则条 +- ⛔ 改本技能包的规则文件、却不过「说人话」这一关（2026-10-07）：规则和产出同一把尺子 —— 口径见 `product-planning` 的「执行规则」内容准则条 + +## 本段读什么、守什么 + +- 方法论两份：`references/create-prd.md`（功能清单）、`references/state-machine.md`（六项治理清单仍要读，落点变成功能条目内）。 +- 产物模板：`assets/产品规划模板.md`（两张表的表头与顺序的**唯一定义处**；2a／2b 起手都从它复制）。 +- 绘图资产：`assets/diagram-design/`（整树保留，供画布局图）。 +- 贯穿纪律：同一件事只写一遍 —— 同一批人 / 同一批场景若在①②两段各写一份，必然打架。 + +📎 本段收窄前的产出清单与其去向（含方法论去留）见 `_留痕/②段-已删除产出与方法论.md` —— 正文不展开；防复活由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` / `WHITELIST` 机器判。 diff --git a/product-planning/references/_留痕/优化-20261016/references/stage-proto-doc/SKILL.md b/product-planning/references/_留痕/优化-20261016/references/stage-proto-doc/SKILL.md new file mode 100644 index 0000000..3c3cde7 --- /dev/null +++ b/product-planning/references/_留痕/优化-20261016/references/stage-proto-doc/SKILL.md @@ -0,0 +1,186 @@ +--- +name: stage-proto-doc +description: 产品规划第④段，原型说明文档。在③段已跑通的原型 HTML 上补说明区，并产出一份能独立阅读的产品文档：按七节铺开 —— 原型地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值，编号用 P 页面／S 场景／F 功能／J 二级功能，起手复制段内模板 `assets/产品文档模板.html`。当用户要给原型加功能说明区、写产品文档、做操作指引演示，或说「只做原型说明文档」时调用。 +--- + +# ④ 原型说明文档 + +## 定位 + +- 本段解释和记录**现有**原型：不重新规划产品，不重新设计界面。 +- 交付两份产物：原型内嵌说明区、可独立发送的产品文档。两份共用同一套编号、场景、流程与功能定义。 +- 原型是界面行为的核对依据；①段的决策表与②段的功能清单是业务意图的补充依据。 +- 两份产物都按**七节**组织（原型地址／页面结构／功能清单／使用场景／操作流程／页面导航／原型状态取值），骨架与 `assets/产品文档模板.html` 同构；⛔ 不按状态轴分段，也不把原型的界面状态当成文档的层级（界面状态只在第七节里写）。 +- 说明区是注解层，不是产品功能。交付时明说，免得让人以为产品里真有一个说明页。 + +## 输入 + +| 来自 | 读什么 | 用来定什么 | +|---|---|---| +| ③ | `designs/<项目>/*.html` | 界面事实的唯一依据：页面、模块、控件、状态、交互、跳转、反馈 | +| ② | `docs/pm/<项目>/prd/2a-产品功能.md` · `docs/pm/<项目>/prd/2b-界面布局.md` | 术语口径、优先级、功能条目编号 | +| ① | `docs/pm/<项目>/research/1a-需求文档.md` | 需求来源与「不做什么」的边界 | + +- 原型是界面事实，需求资料只定业务意图；两者冲突时显式记录，不静默选一个。 +- **上游缺失时**：先把缺的那一段补出来（②段缺失就先要一份最小术语表）；用户不要补，就在文档里逐处标 `【假设】`，并在段末的偏离单里写明「本段未判术语一致」。 +- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来停下问用户，不猜。 + +顺序 4a → 4b → 4c。说明区先齐，再放演示引导。 + +## 4a 场景盘点（必做，最先） + +读 `references/doc-area-spec.md`。产出：页面清单（`P`）＋ 使用场景清单（`S`）＋ 功能清单（`F`）＋ 二级功能（`J`），编号先占好、各自全篇唯一并按展示顺序通排。 + +## 4b 说明区（两份产物） + +读 `references/doc-area-spec.md` 铺框架，读 `references/doc-language-spec.md` 定语言：两份产物写完后，逐句过它第五节的自检清单。 + +**产物 A · 原型内嵌说明区** + +- 写进原型 HTML 自身，不依赖外链。 +- 放在原型对应位置的下方，随当前所在的那一段一起变。 +- 含原型地址、页面结构、功能清单、使用场景、操作流程、页面导航、原型状态取值七节。 +- 不覆盖业务区域，不改既有交互逻辑；原型结构不适合直接嵌入时，给可插入的 HTML 片段与插入位置。 + +**产物 B · 独立产品文档** + +- 单独一个 HTML 文件，落 `designs/<项目>/<产品项目名>.html`（**文件名＝产品项目名**），双击能开，能单独发给不看原型的人。 +- ⭐ **起手先复制通用模板**：`assets/产品文档模板.html`（本段自带）。它已经定好七节骨架、页面地址清单、页面结构图、功能清单（含目标产品特有列）、场景表、横向流程图、页面导航、状态取值表；把 `<尖括号>` 占位逐个换成真实内容即可，⛔ 不要从空白页重写结构。 +- 模板里定死的口径，照着填：编号 P／S／F／J 各自全篇唯一并按展示顺序通排；功能区命名用用户的叫法；流程画成**横向**流程图且每步写清「页面／功能／操作／完成判据」，「操作」行用强调色；重点功能在功能名、说明、目标产品特有列三处同时标红。 +- 七节顺序固定，与模板同构（见下面「产品文档框架」一节）。 + +## 4c 演示引导（可选） + +读 `references/guided-tour.md`，给每条流程放「演示」按钮。**用户不要演示时整体跳过**，跳过就在段末写明「本段未做演示引导」，完成标准里对应的那几条一并免检。 + +## 产品文档框架（七节 · 与 `assets/产品文档模板.html` 同构） + +⭐ **起手先复制通用模板** `assets/产品文档模板.html`（本段自带）：它已定好七节骨架、页面地址清单、页面结构图、功能清单（含目标产品特有列）、二级功能表、使用场景表、横向流程图、页面导航、状态取值表；把 `<尖括号>` 占位逐个换成真实内容即可，⛔ 不要从空白页重写结构。 +模板里定死的口径照着填：编号 `P`／`S`／`F`／`J` 各自全篇唯一并按展示顺序通排；功能区命名用原型界面上的叫法；流程画成**横向**流程图；重点功能在功能名、说明、目标产品特有列三处同时标红。 + +### 一、原型地址 + +- 每个原型页一行相对链接：文件名 ＋ 一句它是什么；放在文档最前。 +- ⛔ 不写本机绝对路径，⛔ 不写说明句 —— 读者直接点开就行。 + +### 二、页面结构 + +- 给一张页面结构图，图上标出各页面与其下的功能编号（页面 `P00x`／功能 `F00x`）。 +- 页面层级写一级／二级；功能区命名用原型界面上的叫法。 + +### 三、功能清单（表格） + +列：序号／页面名称／层级／功能区／功能（`F00x` ＋ 名称）／功能做什么／功能细节／目标产品特有列（本项目＝租户列）／待开发。 + +- 一行 = 一项功能；功能名与原型界面上的叫法一致。 +- 重点功能在功能名、说明、目标产品特有列三处同时标红，并在「重点项」表里补一行（重点项／说明／相关编号）。 +- 二级功能（一项功能展开的多个选项）另起一张表：编号 `J001`…／二级功能项／产出什么／对应页面功能。 +- 模板列之外，每项功能还要补齐这四项才算写完： + **做什么** —— 写处理行为与可观察结果，不写功能口号。 + **入口在哪** —— 给到可定位的页面与控件。 + **输入边界** —— 覆盖输入类型、必填、格式、长度、范围；无输入的功能写「无用户输入」。 + **异常与恢复** —— 写异常触发条件、界面反馈、恢复操作；原型没体现就写「原型未体现」，不写成已实现。 + +### 四、使用场景 + +- 一行 = 一个场景，写「用户要办成的一件事」，不写模块名；编号 `S001`…。 +- 每条带 前提／目标／原型位置（写到「页面 → 模块 → 控件或状态」，能在原型上点到）。 +- 场景后标该场景下的条目数。 + +### 五、操作流程（横向流程图） + +- 每个场景一条横向流程图，每步写清 页面／功能／操作／完成判据，「操作」行用强调色。 +- 步骤链 2–6 步；起点满足场景前提，终点对应场景目标。 +- 步骤里的按钮、菜单、字段、状态名称与原型逐字一致；流程里不出现原型没有、也没确认过的操作。 + +### 六、页面导航 + +- 一条导航一段，写成「来源页 → 目标页」＋走法；单向跳转与打开方式一并写明。 +- 原型没体现的跳转写「原型未体现」，不写成已实现。 + +### 七、原型状态取值 + +- 一行一个取值，写清取什么值落在哪个界面。 +- 取值与状态名一律以原型为准；⛔ 不把页面层级当状态写。（已验证过 `?state=` 这类取值清单的界面，走这条；无此机制的原型写「无」） + +## 编号与关联 + +- 页面 `P001`…、使用场景 `S001`…、功能 `F001`…、二级功能 `J001`… —— 各自全篇唯一、按展示顺序通排。 +- 同一场景、同一功能在不同章节重复出现时复用同一编号。 +- 每项功能至少挂在一个页面（`P00x`）上，挂不上就标「未映射」。 +- 二级功能 `J00x` 必须标出它对应的 `F00x`。 +- 功能可以服务多个场景；多对多时逐项列出关联编号。 +- 页面、模块、控件的数量不等于功能数量。 + +## 语体口径 + +- **完整规范读 `references/doc-language-spec.md`**：术语来源优先级、逐条禁用清单、五组对错对照、以及一份逐句自检清单。写每一句都照它过，自检任一项不通过就改。 +- 元信息（条数、口径、读法）写进表格的列、条目的字段或表头里；标题后面与标题下面都不另起说明行（踩过的坑：在标题下用小字解释「这一节是什么、为什么这么排」，2026-10-14 用户第三次点名，前两次分别是原型的状态小字与章节注解）。 +- 客观、书面的说明文，一句话只表达一个主要意思。 +- 用确切的页面名、模块名、控件名、状态名与业务术语；同一个概念全篇同名。 +- 描述行为用可验证的动词：显示、输入、选择、提交、生成、跳转。 +- 区分「已实现／未实现／待确认」三种状态，各写各的。 +- **禁用清单**：营销话术、主观评价、模糊程度词（大概、尽量、适当）、无依据的效果承诺、「相关页面／适当提示／处理异常」这类无法定位的说法、第一人称、比喻、空转评价（「值得注意的是」「具有重要意义」）。 +- 缺失信息明确标记，不用推测性描述填空白。规则文件本身也用这套语体写。 + +## 硬约束 + +- 只用原型上真实存在的事实；每条说明都能在原型上指到对应元素。 +- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。 +- 不擅自新增页面、功能、需求、业务规则或交互。 +- 把静态展示与真实数据处理能力分开写；把模拟数据、模拟提交、演示反馈与真实后端能力分开写。 +- 把计划实现与已实现分开写。 +- 不遗漏编号，不重复分配编号。 +- 两份产物的名称、编号、范围、入口、行为描述必须一致。 +- 说明区不依赖外链，不破坏原型原有功能。 +- 原型与需求资料的差异显式记录。 +- 自动结论不写成人工认可：机器判定只能说「进入队列／待人工逐条查看」，不写成「通过／已认可」。 +- 段内不反问，做完直接进下一个子步；停线规则见 `product-planning` 的「执行规则」。 +- 原型是生成物时，改动走它自己的生成链，不手改产物。 +- ⭐ 文档前面必须配图（2026-10-15 用户令）：本段落盘的每份文档，正文（第一张表 / 第一小节）之前必须先给一张图 —— 本段画《页面结构图 ＋ 用户路径图》；用 `diagram-design` 画，⛔ 手写 Mermaid。图是正文内容，⛔ 不写成标题旁边或标题下面的注解小字。 + +## 完成标准 + +- 独立产品文档含规定的七节，顺序固定，双击能开（起手用 `assets/产品文档模板.html`）。 +- 原型内嵌说明区能在原型里直接找到并读到。 +- 每条使用场景有唯一编号 `S00x`，并带前提、目标、原型位置。 +- 每条场景至少一条横向流程，每条 2–6 步且能在原型中逐项核对；在原型上点不出结果的场景标 `funcOnly`（只写进功能清单、不画流程），并在段末待确认清单里写明为什么点不出来。 +- 每项功能的 做什么／入口在哪／输入边界／异常与恢复 都填了（编号 `F00x`）；二级功能标出对应的 `F00x`。 +- 引用的编号都存在，页面／场景／功能／二级功能四类各自唯一且按展示顺序通排。 +- 两份产物没有互相矛盾的描述。 +- 未确认事项都有标记，并在段末列出待确认清单。 +- 原型原有页面与交互通过回归检查。 +- ⭐ 独立产品文档前面配了页面结构图（用 `diagram-design`，⛔ 无手写 Mermaid） + +## 自查清单 + +- [ ] 输入原型能运行、关键交互能走完 +- [ ] 实际实现／模拟行为／待确认三者的界线划清了 +- [ ] 独立产品文档按七节顺序排好，起手用了 `assets/产品文档模板.html` +- [ ] 页面结构图已配（用 `diagram-design`，⛔ 无手写 Mermaid） +- [ ] 页面 `P00x`／场景 `S00x`／功能 `F00x`／二级功能 `J00x` 各自唯一且按展示顺序通排 +- [ ] 每条场景有前提、目标、原型位置 +- [ ] 每个场景一条横向流程，每条 2–6 步，每步写清页面／功能／操作／完成判据 +- [ ] 每项功能的 做什么／入口／输入边界／异常与恢复 都填了 +- [ ] 重点功能在功能名、说明、目标产品特有列三处同时标红 +- [ ] 二级功能都标了对应的 `F00x` +- [ ] 界面名称与原型逐字一致 +- [ ] 失效编号、孤立功能、未映射功能已清理 +- [ ] 两份产物同一套定义、可相互核对 +- [ ] 说明区没破坏原型运行 +- [ ] 上游缺失处已标 `【假设】` 并写进偏离单 +- [ ] 未做演示引导时已写明并免检对应条目 + +## 反面清单 + +- 只写页面介绍，不写需求、场景、流程和功能 +- 用功能模块代替需求，需求条数没法统计 +- 用「用户使用系统」这类泛化描述代替具体场景 +- 用「点击按钮后完成操作」代替可核对的步骤与结果 +- 用「支持多种格式」代替明确的输入边界或待确认标记 +- 用「发生错误时提示用户」代替异常条件、反馈和恢复路径 +- 把原型里的静态假数据写成真实业务数据 +- 把未实现、未验证、未定义的行为写成既有能力 +- 两份产物里功能名称、编号或流程对不上 +- 改原型业务逻辑去迎合文档描述 +- 以篇幅、术语数量或排版代替可验证的完整性 diff --git a/product-planning/references/_留痕/优化-20261016/references/stage-requirements/SKILL.md b/product-planning/references/_留痕/优化-20261016/references/stage-requirements/SKILL.md new file mode 100644 index 0000000..aadc611 --- /dev/null +++ b/product-planning/references/_留痕/优化-20261016/references/stage-requirements/SKILL.md @@ -0,0 +1,198 @@ +--- +name: stage-requirements +description: 产品规划第②段，产品功能。只做一件事：把①段《使用场景》（`1e-使用场景.md`）细化成功能清单（做哪些 / 不做哪些 / 优先级），并钉死页面骨架（《界面布局》：有哪几页、每页几个板块、板块怎么排、跨页关系）。当用户要写②段两份、列产品功能、定优先级、梳理功能、定页面与板块布局，或说"只做产品功能"时调用。 +--- + +# ② 产品功能 + +回答「要做哪些产品功能、哪些明确不做、页面骨架怎么排」。产出两份： +`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单）＋ `docs/pm/<项目>/prd/2b-界面布局.md`（页面骨架）。 + +> 段名与①「产品需求」构成 `产品需求 → 产品功能 → 界面交互 → 原型说明` 的对称链，四段各占一个词（产品 / 功能 / 界面 / 说明），无一词共用（2026-10-02 用户定）。旧名「需求与结构」「界面与交付」已废。 +> +> 与①段的分界：①回答「要解决什么问题、用户怎么用它」，②回答「要做哪些功能、长成什么骨架」。判据看文档主体 —— 主体是功能条目的有无与优先级、页面与板块骨架，归②；主体是问题、用户、取证与取舍理由，归①。 +> +> ⭐ 2026-10-06 用户定案：本段收窄为「只细化功能」。2026-10-07 用户定案「2 产品功能 和 界面布局不就是两个文档嘛」，两件事各成一份：产品功能（做什么）＋ 界面布局（长什么样）。（①段侧的定案原话与 grill 归属见 `stage-discovery`，本段不复述。） +> +> 本段就这两份：`docs/pm/<项目>/prd/2a-产品功能.md`（功能清单）＋ `docs/pm/<项目>/prd/2b-界面布局.md`（页面骨架）。 +> +> 别处的内容在本段怎么落地：状态流转与优先级都写进每条功能自己，不单独成文；用户故事取①段《使用场景》（`1e-使用场景.md`），本段按它推功能；grill / 压测在①段 1a（全场唯一一份 `grill-me`）；风险取①段《产品策略》的「假设与风险」。 +> +> （历史：本段收窄前的产出清单与其去向 → `_留痕/②段-已删除产出与方法论.md`） + +## ⭐⭐ ②—③ 交接口（唯一权威处 · 改边界只改这一块 · 2026-10-06 用户定案） + +> 🔴 「②段管什么、③段管什么」**只在本节定义一次**。本段其余章节、总入口 `product-planning/SKILL.md`、 +> `stage-discovery` 与 `stage-delivery` 的 `SKILL.md`、③段 `references/execution-runbook.md` 与 +> `references/layouts-tooling.md`，提到这条边界时一律**引用本节的行名**，⛔ 不许再复述清单。 +> 为什么立这一块：同型的复述病已经造成过真事故 —— 停线规则被三段写成「三种、②段写成「四种」， +> 两边长期漂着而没有任何门禁会报。单一可信源才拦得住。 +> 用户原话（本节的唯一出处，别处不再抄）：「3 是负责设计和交互，页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子」。 + +口径：②段钉骨架，③段做皮肉。 + +| 归②段（必须在本段定死） | 归③段（⛔ ②段不许写） | +|---|---| +| 有哪几页 | 配色 / 字体 / 间距 / 组件样式 / 动效 | +| 每页几个板块、板块怎么排 | 每个板块的视觉实现（怎么好看、怎么对齐、什么层次） | +| 跨页关系（怎么跳转） | 每个板块的交互行为（点哪、什么反馈、何时不可点） | +| 每页的主操作是什么 | 状态与空态的具体呈现 | +| 每条信息在哪一档承载（主屏常驻 / 可点入） | 响应式怎么变 | + +> ⭐ 骨架是判断基准，必须在②段定死。旧口径把「有哪几页」留在③段，结果就是③段做一版一个样，②段无从判断改得对不对。 +> ⛔ 交给③段时骨架是冻结的：③段不许新增 / 移动 / 删除板块，缺板块要回②段改。 +> 「归③段」那一列的六个词就是本段的**零视觉词红线**：本段其余章节与 `references/create-prd.md` 提到它时， +> 一律写成「见 §②—③ 交接口 的『归③段』列」，⛔ 不再逐处抄这六个词。 + +## 本段职责（2026-10-06 按「只细化功能」重划） + +本段回答一个问题：把①段的使用场景细化成哪些功能，这些功能长成一个什么骨架。拆成两问（原三问）： + +| 问 | 内容 | 落点 | +|---|---|---| +| 有哪些功能、优先级如何、什么不做 | 从每条使用场景推出功能条目；每条带优先级、状态流转、验收要点 | `2a-产品功能.md` | +| 这些功能长成什么骨架 | 有哪几页、每页几个板块、板块怎么排、跨页关系 | `2b-界面布局.md` | + +> ⭐ 本段产物的主体是功能条目的有无与优先级，这也是「产品功能」这个名字的依据。实测本项目 **24 条**功能定义（`F001`–`F024`）**落在④段产品文档**，②段 `prd/` 为空 —— 「功能落在哪段」按实际记，⛔ 不要拿本段的定位当既成事实写。 +> ⛔ 本段不许重开需求：需求澄清、grill 反问、取证都在①段做完了。本段假定需求已成立，只做功能取舍。 +> ⭐ 功能按使用场景组织（2026-10-06 用户定案），一条使用场景下可能放跨多个页面的功能。用户原话：「功能可以分使用场景梳理（可能是跨页面的）」。不按页面组织 —— 按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上。 + +## 2a 产品功能 + +| 子步 | 读 | 产出 | +|---|---|---| +| 2a 产品功能 | `references/create-prd.md` | `docs/pm/<项目>/prd/2a-产品功能.md` | + +回答：要做哪些功能、哪些明确不做、每条什么优先级、每个功能自身怎么流转。 + +⭐ **起手先复制模板**（2026-10-16 补）：`assets/产品规划模板.md` 的「一、功能清单」那张 12 列表 —— 表头与顺序照抄，把 `<尖括号>` 占位换成真实内容，⛔ 不要从空白页重写结构。 + +## 2b 界面布局 + +| 子步 | 读 | 产出 | +|---|---|---| +| 2b 界面布局 | `assets/diagram-design/SKILL.md`（第三方 skill 整树保留，其 `references/`、`scripts/`、`assets/` 路径均相对该目录解析） | `docs/pm/<项目>/prd/2b-界面布局.md` | + +回答：有哪几页、每页几个板块、板块怎么排、跨页关系怎么跳。 + +⭐ **起手先复制模板**（2026-10-16 补）：`assets/产品规划模板.md` 的「二、页面骨架」那张 8 列表 —— 表头与顺序照抄，把 `<尖括号>` 占位换成真实内容，⛔ 不要从空白页重写结构。 + +> 顺序是 2a → 2b：布局是功能清单的空间展开，功能还没定就画布局等于凭空发明版面。 +> ⛔ 2a 之前不再需要压测步骤，压测已前移①段 1a 的 B 节。 + +### 功能清单怎么组织（逐条可核） + +每个功能条目必须带齐这几样： + +| 字段 | 写什么 | 判据 | +|---|---|---| +| 功能名 | 一句话说清做什么（动词开头的用户语言） | ⛔ 不写实现名 | +| 来自哪条场景 | 追回①段《使用场景》（`docs/pm/<项目>/research/1e-使用场景.md`）的编号 | ⛔ 追不回的条目该砍 | +| 优先级 | P0 / P1 / P2 | 见下方「优先级」 | +| 状态流转 | 这个功能自身有哪几个状态、怎么迁移（不适用就写「无状态」） | ⛔ 不许省成空白 | +| 验收要点 | 怎么算做完（可观察） | ⛔ 不写「体验好」这类 | +| 跨哪些页面 | 这个功能在骨架的哪几页上发生 | 可为多页 | + +🔴 **输入缺失时怎么办（②段唯一分支，2026-10-16 补）**：「来自哪条场景」这一列的输入是①段《使用场景》；它缺失时（`1e-使用场景.md` 不存在，或①段收口时把它列进了豁免清单）⇒ **退化为追回 `1a` 决策表**： + +1. 到 `docs/pm/<项目>/research/1a-需求文档.md` 的决策表里逐条认领（A 节「问题与边界」／B 节「形态与状态」），把这一列改标成「来自 `1a-需求文档.md` §<节号>-<条目>」。 +2. 两条都追不到（`1e` 与 `1a` 都没有对应条目）⇒ 该功能条目**砍掉**，并写明「无需求来源，已砍」。 + +⛔ 不许因为上游缺文件就把这一列放空或写「未定」—— 那样「功能该不该有」就没有判据了。 +⛔ 也不许反过来：`1e` 与 `1a` 都在时，一律以 `1e` 为准，退化只在**缺失**时启用。 + +优先级（⛔ 不许凭空打分，见硬约束）： +- P0：不做则①段某条使用场景整条办不成 +- P1：不做则场景能办成但要多绕（本可用一次点击，变成三步） +- P2：不做不影响场景办成，只是更好用 + +> 优先级判据 = 一句可复述的话。本项目没有数据源，不填数字。 + +### 2b 界面布局怎么写 + +本份专管界面骨架，⛔ 不写功能条目的有无与优先级（那是 `2a-产品功能.md`）。一句话分工：`2a` 管「做哪些事」，`2b` 管「这些事落在哪几页、每页长什么结构」。 + +🔴 **骨架怎么来（2026-10-16 补）**：现读**目标产品整页快照**再挑板块 —— 路径与③段同源：`references/stage-delivery/assets/design-systems/<选定套>/assets/component-library/snapshot/<板块>.html`。②段从快照的板块集里**挑**（挑哪几块、怎么排），③段按挑好的骨架**做**；板块名一律照抄快照，⛔ 不许自造（第 1 轮返工的病根就是自造 `nav-item` × 21）。本项目真正用到的快照是 `snapshot/script.html`：选不到对应板块时，写明用的是哪一份快照、为什么。 + +| 问 | 回答 | 内容 | +|---|---|---| +| 页面关系 | 有哪几页、门开在哪、**新功能放在已有产品的哪一页** | 页面清单、页面流转、导航、**已有产品的页面 ＋ 新增块** | +| 页面内布局 | 房间里家具怎么摆 | 每页的板块清单 ＋ 排列顺序（wireframe 灰块粒度） | + +> ⭐ 拆成两份是 2026-10-07 的用户定案。旧写法一份装两半，同一件事要写两遍（比如 `header / side / footer` 既像页面框架又像页内板块）；拆开后各自只写自己那一侧，正好逼着把边界写明确。 +> 🔴 防重写规则（拆开后必须守）：页面级框架（`header / side / footer`）只在 `2b` 写一次；`2a` 的功能条目里只许出现「跨哪些页面」，⛔ 不许描述页面长什么样。 +> ⚠️ 粒度：本段给灰块框图（有哪些块、什么顺序），⛔ 不给视觉（颜色、字体、间距、圆角、层次）。视觉类六词（见 §②—③ 交接口 的『归③段』列），本段（含布局）仍不许写。 +> ⚠️ 旧 `ux/diagrams/system-architecture.html` 画的是系统组件之间的关系，属实现视角，已改名。本段要的是页面与板块，属产品视角，⛔ 不许再叫「系统架构」。 + +## 硬约束 +- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。 + +- ⭐ 本段不是压测入口（2026-10-06）：`grill-me` 全场只有①段一份，火力点已扩到覆盖「做成什么样、状态怎么流转」。⛔ 本段不许再开一轮反问 —— ①段 `1a-需求文档.md` 的决策表就是本段的压测输入。用户始终不回应时①段怎么处理，本段照旧继承，但不再自己去问。 +- ⭐ 假设照旧继承，但账在①段：`1a-需求文档.md` 带进来的每条 `【假设】`，在②段落盘时逐条给结论，只允许三种归宿 —— 已确认（写明确认人与时间）｜待实现且已排定确认时机（写明「在第几步落地前必须问」）｜`【已按假设落地】`（写清影响面 + 回退口径）。⛔ 第四种（既未确认、已进实现、又无落地说明）不许带进本段。 + - ⭐ 引用假设必须带状态：本段任何一条功能 / 状态流转 / 分档，只要依据是某条假设，就在括号里带上该假设的当前状态（`（依据 Q7 · 已确认）`、`（依据 Q10 · 【已按假设落地 · 影响面：每版全量复制 → 版本目录体积】）`）。下游③段据此判断这条能不能当硬约束用。 + - ⭐ 假设与实测要回头对账：凡靠假设得出的结论，一旦下游跑出实测结果，必须回填并改状态。实测踩坑：`PRD.md:132` 假设 3「单文件 HTML 在 `file://` 下能双击打开（③段需实测）」标着待实测，而③段早已实测了 16 版，事实成立却没人回填。 +- ⭐ 待确认 / 暂缓项必须带回收三字段（2026-10-02）：本段任何「待确认 / 暂缓 / 待定」条目必须同时写 复核人 ＋ 复核时机 ＋ 结论落点（哪个文件哪一节），三字段缺一不许落盘。⛔ 只写「暂缓」等于无限期搁置。 +- 「不做 / 移出」必须逐条核对，不许自行裁剪：写②段前、落盘后各做一次 —— 把②段里每一条「不做 / 移出 / 暂缓」与 `1a-需求文档.md` 的已拍板项逐条对照。凡涉及已拍板项，一律不得自行裁剪或改口径，必须列成「与已定决策的差异」表（原条目 / 原口径 / 拟改口径 / 理由）交用户显式确认。只写「已核对无冲突」不算核对，要给出对照过的条目数。 +- ⭐ 每条功能必须能追回①段《使用场景》（`1e-使用场景.md`）：追不回的功能就要么补一条场景、要么砍掉。这是本段唯一的功能有无判据，代替凭空打分。 +- ⭐ 状态流转写在功能条目里，⛔ 不再单独成文（2026-10-06）：每个功能条目自带「状态流转」字段。六项治理照旧全覆盖（失败恢复路径、持久化范围、并发冲突、幂等、超时迁移目标、不可逆操作二次确认），只是落点从独立文档移进功能条目。 + - ⭐ 状态放不到任何功能上的中间态，要么删掉，要么补一个功能条目让它服务。 +- ⭐ 骨架必须给全（2026-10-06）：②段的《界面布局》必须给全 §②—③ 交接口 的「归②段」列那几样，逐条对应。⛔ 缺任何一样，③段就没有方向。 + - 信息承载分档的判据：「删掉它，主操作还做得成吗」—— 答「做得成」就只能进「可点入」。⛔ 「能读到」= 可点入，不等于主屏常驻；不许以「②段要求能读到」为由把信息留在主屏。 +- ⛔ 本段（含布局）不许写视觉（六词清单见 §②—③ 交接口 的『归③段』列），一个字都不许出现。 +- ⭐ 文档前面必须配图（2026-10-15 用户令）：本段落盘的每份文档，正文（第一张表 / 第一小节）之前必须先给一张图 —— 本段画《页面与功能结构图》；用 `diagram-design` 画，⛔ 手写 Mermaid。图是正文内容，⛔ 不写成标题旁边或标题下面的注解小字。 +- 段内不反问，做完直接往下走。停线规则（哪几种情况停、怎么判）见 `product-planning` 的「执行规则」—— ⛔ 本段不复述，免得两处漂。 +- `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。 + +## 完成标准 + +- `2a-产品功能.md` 与 `2b-界面布局.md` 两份都在，且只有这两份（⛔ 不许再产出 `grill-decisions` / `user-stories` / `priorities` / `pre-mortem` / `state-machine` / `diagrams` 六份中的任何一份；⛔ 也不许再退回单份 `PRD.md`） +- ②段的「不做 / 移出」清单逐条对照过①段已拍板项，差异行为 0 或每一行都已获用户显式确认（附对照条目数，不得只写「无冲突」） +- 功能清单每条带齐「功能名 / 来自哪条场景 / 优先级 / 状态流转 / 验收要点 / 跨哪些页面」六字段；⛔ 追不回①段场景的条目为 0 +- 状态流转六项治理全覆盖（失败恢复 / 持久化 / 并发 / 幂等 / 超时 / 不可逆二次确认），且落在功能条目内 +- 《界面布局》给全 §②—③ 交接口 的「归②段」列（含分档判据回答） +- ⛔ 全文零视觉词（六词清单见 §②—③ 交接口 的『归③段』列） +- 每条假设都有归宿（三选一，无第四种）；凡依据假设的功能 / 状态流转 / 分档，条目里都带上了假设状态标注 +- ⭐ 2a 与 2b 两份前面都配了图（用 `diagram-design`，⛔ 无手写 Mermaid） +- 本段所有「待确认 / 暂缓」条目都带齐 复核人 / 复核时机 / 结论落点 三字段 +- ⭐ 两份都过了「说人话」内容准则（源技能、判据与门槛见 `product-planning` 的「执行规则」内容准则条）；段末报告须写明「已过内容准则，评分 X/50」 + +### 六条可机核项（2026-10-16 补 · 逐条给读数，⛔ 不许只写「已核对」） + +| # | 判据 | 怎么核 | +|---|---|---| +| 1 | **页面清单条数 ＝ 原型 `.html` 文件数** | 数 `2b` 的「页面名」列行数，与 `designs/<项目>/*.html` 里**原型页**的个数比对（⛔ 产品文档、`3c-*`、`3d-*` 不算原型页） | +| 2 | **既有页沿用的板块名 ∈ 目标产品整页快照的板块集；新增页的功能区名允许自定、但须写明依据** | 拿 `2b` 的「板块清单」列逐名去 `snapshot/<板块>.html` 里 grep：**快照里有的**必须逐字命中；**只在新增页出现的**允许自定，该行须写明「新增页 · 依据」（照 §骨架怎么来 的活口）；⛔ 给既有页自造假块名一律报红 | +| 3 | **功能条目数 ＝ ④段产品文档的 F 条数，且 F 编号唯一连续** | 数 `2a` 的 F 行数，与成品〈三、功能清单〉的 F 条数比对；再验 `F001…F00N` 无跳号无重号 | +| 4 | **每条 F 带齐**：场景编号（或退化后的 `1a` 条目）／优先级／状态流转／验收要点 | 逐行查四列非空；⛔「未定」「暂缓」不算已填 | +| 5 | **2a 的页面名／功能区在 2b 全追得到；2b 挂的 F 在 2a 全追得到** | 两个差集都要为空，读数写「正向 N 条全中／反向 M 条全中」 | +| 6 | **全文零视觉词**（清单见 §②—③ 交接口 的『归③段』列） | 逐词 grep 两份产物，命中数须为 0 | + +## 反面清单 + +- ⛔ 在本段重开一轮 grill 反问（2026-10-06）：反问已整套前移①段 1a，本段只细化功能 +- ⛔ 产出本段两份之外的文档（本段只 `2a` 与 `2b`，白名单由 `check_naming.py` 机器判） +- ⛔ 把「产品功能」与「界面布局」又塞回一份（2026-10-07 用户定案：这就是两个文档） +- ⛔ `2a` 里描述页面结构 / `2b` 里写功能条目的有无与优先级（越界即重写） +- ⛔ 按页面组织功能清单（2026-10-06）：功能要按使用场景组织，一条场景可跨多页；按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上 +- ⛔ 凭空给功能打分（Importance × Satisfaction / ICE / RICE）：没有数据源。优先级只能是 P0/P1/P2 + 一句可复述的判据 +- ⛔ 功能条目追不回①段《使用场景》（`1e-使用场景.md`）：追不回就要么补场景、要么砍条目 +- 用「移出第一版 / 不做」自行砍掉已拍板项，或只声称「已核对无冲突」却不列对照条目数 +- 在本段重开需求验证（该做取证与需求定义的是①段；本段假定需求已成立，只做功能取舍） +- ⛔ 骨架给不全（2026-10-06）：只给页面清单、不给每页板块与排列，或只给布局、不给跨页关系 —— ③段拿不到方向，就会一版一个样 +- ⛔ 把某条信息标为「主屏常驻」却答不上「缺了主操作就做不成事」：按判据应归「可点入」 +- 状态流转只画正常路径，不管失败与并发；或状态放不到任何功能条目上（凭空中间态） +- ⛔ 在本段写视觉（清单见 §②—③ 交接口）—— 那是③段 +- 越界去出原型或写说明文档（那是第③④段） +- 把 `【假设】` 原样带进②段当既定事实；或假设已被实现却从不回填状态 +- 只写「暂缓」而不给复核人 / 复核时机 / 结论落点 —— 等于让这条永远放着 +- ⛔ 两份没过「说人话」内容准则就落盘 —— 口径与门槛见 `product-planning` 的「执行规则」内容准则条 +- ⛔ 改本技能包的规则文件、却不过「说人话」这一关（2026-10-07）：规则和产出同一把尺子 —— 口径见 `product-planning` 的「执行规则」内容准则条 + +## 本段读什么、守什么 + +- 方法论两份：`references/create-prd.md`（功能清单）、`references/state-machine.md`（六项治理清单仍要读，落点变成功能条目内）。 +- 产物模板：`assets/产品规划模板.md`（两张表的表头与顺序的**唯一定义处**；2a／2b 起手都从它复制）。 +- 绘图资产：`assets/diagram-design/`（整树保留，供画布局图）。 +- 贯穿纪律：同一件事只写一遍 —— 同一批人 / 同一批场景若在①②两段各写一份，必然打架。 + +📎 本段收窄前的产出清单与其去向（含方法论去留）见 `_留痕/②段-已删除产出与方法论.md` —— 正文不展开；防复活由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` / `WHITELIST` 机器判。 diff --git a/product-planning/references/_留痕/优化-20261016/references/stage-requirements/assets/产品规划模板.md b/product-planning/references/_留痕/优化-20261016/references/stage-requirements/assets/产品规划模板.md new file mode 100644 index 0000000..4185e07 --- /dev/null +++ b/product-planning/references/_留痕/优化-20261016/references/stage-requirements/assets/产品规划模板.md @@ -0,0 +1,58 @@ +# ②段产品规划模板（起手先复制本件） + +> 🔴 **怎么用**：起手先复制本模板，把 `<尖括号>` 占位**换成真实内容**，⛔ 不要从空白页重写结构。 +> 本件是②段两份产物的**体例单一定义** —— 两张表的表头与顺序都在这里定死： +> 落 `2a-产品功能.md` 时只抄「一、功能清单」那张表；落 `2b-界面布局.md` 时只抄「二、页面骨架」那张表。 +> **表头一行照抄**，⛔ 不许增删列、不许改顺序；列名里的 `<项目>` 按 `product-planning` 的「项目与路径约定」换成真实 slug。 +> 两份文档开头那张图（`diagram-design` 画的《页面与功能结构图》）按各自硬约束插在**标题之后、第一张表之前** —— 本模板不代画。 +> ⚠️ 第③段已有的成品（`designs/<项目>/<产品项目名>.html` 的「三、功能清单」一节）是**列取材来源**，但它少了本段自有的四项（`来自哪条场景`／`优先级`／`状态流转`／`验收要点`）⇒ **照成品抄一遍会把②段的判据抄丢**，必须用下面这张 12 列的表。 + +--- + +## 一、功能清单（→ `docs/pm/<项目>/prd/2a-产品功能.md`） + +| 编号 | 页面名称 | 层级 | 功能区 | 功能 | 功能做什么 | 功能细节 | 来自哪条场景 | 优先级 | 状态流转 | 验收要点 | 本期做不做 | +|---|---|---|---|---|---|---|---|---|---|---|---| +| F001 | `<页面名>` | `<一级／二级>` | `<功能区名>` | `<功能名：动词开头的用户语言>` | `<一句话说清做什么>` | `<具体有哪些操作与显示，逐条>` | `S001` | `P0` | `<有哪几个状态、怎么迁移；无状态写「无状态」>` | `<可观察的完成判据>` | `<本期做／移出（移出须写复核时机）>` | +| F002 | `<页面名>` | `<一级／二级>` | `<功能区名>` | `<功能名>` | `<一句话>` | `<逐条>` | `S002` | `P1` | `<…>` | `<…>` | `<…>` | + +**列口径**（12 列，⛔ 不许省）： + +| 列 | 写什么 | 判据 | +|---|---|---| +| 编号 | `F001`、`F002`… 唯一且连续 | «编号唯一且连续» 是机核项；⛔ 不跳号 | +| 页面名称 | 这个功能落在哪一页；跨多页写多页名，用「／」分隔 | 每一个页面名都要能在 `2b-界面布局.md` 的「页面名」列里追到 | +| 层级 | 一级页／二级页 | 与 `2b` 同页的值一致 | +| 功能区 | 页面里的哪个功能区（页内分组名） | 同上，须能在 `2b` 追到 | +| 功能 | 功能名，一句话说清做什么（动词开头的用户语言） | ⛔ 不写实现名 | +| 功能做什么 | 一句话讲清用户拿它干什么 | ⛔ 不写「体验好」这类 | +| 功能细节 | 具体有哪些操作与显示，逐条列 | ⛔ 不许空着 | +| 来自哪条场景 | ①段《使用场景》的编号（`S001`…）；**`1e-使用场景.md` 缺失时**退化为追 `1a-需求文档.md` 决策表条目（写法见 `SKILL.md` 的「输入缺失时怎么办」） | ⛔ 追不回的条目该砍 | +| 优先级 | `P0`／`P1`／`P2` | ⛔ 不许凭空打分 | +| 状态流转 | 这个功能自身有哪几个状态、怎么迁移（不适用写「无状态」） | ⛔ 不许省成空白 | +| 验收要点 | 怎么算做完（可观察） | ⛔ 不写「体验好」这类 | +| 本期做不做 | 本期做／移出；写「移出」的必须带复核时机 | ⛔ 只写「暂缓」不算 | + +--- + +## 二、页面骨架（→ `docs/pm/<项目>/prd/2b-界面布局.md`） + +| 页面编号 | 页面名 | 层级 | 对应原型文件 | 板块清单 | 板块排列 | 跨页关系 | 板块下挂哪些 F | +|---|---|---|---|---|---|---|---| +| P001 | `<页面名>` | `<一级／二级>` | `` | `<板块名①；板块名②；…（灰块粒度，只报有哪些块）>` | `<自上而下／左右；顺序逐块列出>` | `<← 来源页：…；→ 目标页：…>` | `F001、F002` | +| P002 | `<页面名>` | `<一级／二级>` | `` | `<…>` | `<…>` | `<…>` | `<…>` | + +**列口径**（8 列，⛔ 不许省）： + +| 列 | 写什么 | 判据 | +|---|---|---| +| 页面编号 | `P001`、`P002`… 唯一且连续 | 机核项；⛔ 不跳号 | +| 页面名 | 页面叫什么 | 机核项：**页面条数 = 原型 `.html` 文件数**（不含产品文档等非原型件） | +| 层级 | 一级页／二级页 | 与 `2a` 同页的值一致 | +| 对应原型文件 | 这一页落在哪个原型文件（相对 `designs/<项目>/` 的文件名） | 文件必须真实存在 | +| 板块清单 | 每页有哪些板块，灰块粒度 | 机核项：**每个板块名都要能在目标产品整页快照的板块集里追到** | +| 板块排列 | 这些板块自上而下／左右怎么排 | ⛔ 不许只给清单不给顺序 | +| 跨页关系 | 从哪一页怎么跳到这一页、这一页怎么跳出去 | ⛔ 不许只给页面清单不给流转 | +| 板块下挂哪些 F | 每个板块承载 `2a` 的哪几条 F 编号 | 机核项：**这里挂的 F 在 `2a` 全追得到，`2a` 的 F 在这里也全追得到** | + +> ⚠️ 视觉类六词（配色／字体／间距／组件样式／动效／响应式…完整清单见 `SKILL.md` 的 §②—③ 交接口「归③段」列）在本模板里**一个字都不许出现** —— 本模板只管灰块粒度的骨架。 diff --git a/product-planning/references/stage-delivery/SKILL.md b/product-planning/references/stage-delivery/SKILL.md index 23a0d6a..6165f4b 100644 --- a/product-planning/references/stage-delivery/SKILL.md +++ b/product-planning/references/stage-delivery/SKILL.md @@ -5,7 +5,7 @@ description: 产品规划第③段，界面交互。设计工程供给默认来 # ③ 界面交互 -回答两个问题：长什么样、怎么操作。产出 `docs/pm/<项目>/DESIGN.md` 与 `docs/pm/<项目>/ui/*.html`。 +回答两个问题：长什么样、怎么操作。产出 `产品原型/designs/DESIGN.md` 与 `产品原型/pages/*.html`。 > 段名为什么是「界面交互」（2026-10-02 定）： > 删「交付」：①②③都产出落盘文件，「交付」是三段共有的属性，不是③的专属；④段也在交付（说明区与独立产品文档），留着会让人以为③管完就结束了。 @@ -24,9 +24,9 @@ description: 产品规划第③段，界面交互。设计工程供给默认来 | 供给位 | 默认来源 | 可选来源 | 管什么 | 用在哪 | |---|---|---|---|---| | 方法主线 | `oil-ui-pro`（全局技能，按技能名引用） | 无 | 方向探索 → 建结构 → 取实证 → 独立评审打分 → 验证交付 | 全段；3a / 3d 最重 | -| 定调与令牌 | 自带样式库 `assets/design-systems/<选定一套>/`（随段携带，现 1 套 `design-system-tiaoyue`） | `<技能根>/open-design/design-systems/<选定一套>/`（153 套） | 调性、全套令牌、组件形态。⚠️ **能力边界（2026-10-08 实测补充）**：自带样式库实测只到**调色板级** —— 语义色 / 圆角 / 字体栈 / 按钮与输入框令牌；**几何与版式不在包内**（栏宽、项高、内衬、间距、组件尺寸一律没有），参考 `design-system.html` 里也**不含源站的界面骨架**。⛔ 不许把「供给在位」读成「已经有设计系统了」；要几何就**回源站实测**或另找来源，拿不到就在 3d 里明说无来源 | 3a 的 D1 | +| 定调与令牌 | 自带样式库 `assets/design-systems/<选定一套>/`（随段携带，现 1 套 `design-system-tiaoyue`） | `assets/open-design/design-systems/<选定一套>/`（153 套） | 调性、全套令牌、组件形态。⚠️ **能力边界（2026-10-13 订正）**：自带样式库**不止调色板级** —— `design-system-tiaoyue/assets/component-library/`（采集于 2026-10-12）含 **9 个板块的整页快照**（`snapshot/<板块>.html`，去脚本、图片 URL 绝对化，7 个板块与线上逐像素一致率 ≥99.3%）、**345 个自有组件族**（`gallery.html` 是可视化总库，带搜索与一键复制 HTML）与**整站 CSS 原样合并**（`tiaoyue-all.css`，53 张 sheet ／ 1.11 MB）。⇒ **有目标产品整页快照就直接改快照当原型页**：打开对应板块的 snapshot（`snapshot/<板块>.html`）、改文案、删模块，立刻得到像素级同款的整页；要单个组件就走组件库的「复制 HTML ＋ 引一次 tiaoyue-all.css」。⛔ 仍不许把「供给在位」读成「不必核对」：快照只反映抓取时刻，JS 运行时状态（轮播帧、滚动位置、动态 class）还原不了，那部分要在 3d 里声明为无来源。（本节 2026-10-08 的原表述「只到调色板级…不含源站的界面骨架」写在 component-library 采集之前，已过期作废。） | 3a 的 D1 | | 版式骨架 | `references/layouts-tooling.md`（工具型页面用） | `<技能根>/open-design/design-templates/web-prototype/`（营销页向；工具型⛔ 不许套） | 工具型九档的名单与判读见 `references/layouts-tooling.md` §0（⛔ 本块不复述名单；2026-10-08 追加「导航栏」一档 = §4.9） | 3b | -| 工艺数值判据 | `references/execution-runbook.md` §3.4 ＋ `references/layouts-tooling.md` §5.5 | `<技能根>/open-design/craft/`（13 份） | 字阶 / 配色 / 状态齐备 / 动效纪律 / 反 AI 味 / 无障碍。⚠️ **未选可选档时，后四项（反 AI 味 / 无障碍 / 动效纪律 / 表单校验）没有供给来源** ⇒ 必须在 `3d-审查报告.md` 里逐项显式记为**本段证据缺口**（写「无供给来源，本项未判」），⛔ 不许默不作声地跳过、也⛔ 不许拿别的判据冒充它过了 | 3a 判据、3d 终检 | +| 工艺数值判据 | `references/execution-runbook.md` §3.4 ＋ `references/layouts-tooling.md` §5.5 | `<技能根>/open-design/craft/`（13 份） | 字阶 / 配色 / 状态齐备 / 动效纪律 / 反 AI 味 / 无障碍。⚠️ **未选可选档时，后四项（反 AI 味 / 无障碍 / 动效纪律 / 表单校验）没有供给来源** ⇒ 必须在 3d 审查的留痕件（`产品原型/designs/3d-审查报告.md`，或用 `DESIGN.md` 的〈审查/核对〉节替代；两者都见 §3d「审计报告落盘」）里逐项显式记为**本段证据缺口**（写「无供给来源，本项未判」），⛔ 不许默不作声地跳过、也⛔ 不许拿别的判据冒充它过了 | 3a 判据、3d 终检 | | 独立评审协议 | `oil-ui-pro` 的 `references/visual-review.md` ＋ `references/tools.md` | 无 | 没看过制作过程的评审打分 ＋ 截图取证 | 3d | | 多方向比选 | `oil-ui-pro` 的 `references/design-direction.md` ＋ `references/style-explorer.md` | 无 | 方向卡与风格对比页 | 3a 按需 | @@ -51,13 +51,13 @@ description: 产品规划第③段，界面交互。设计工程供给默认来 | 组件形态 | 同目录 `references/components.md` ＋ `references/design-system.html`（组件族清单 `references/library.json`） | | 已知冲突 / 取舍记录 | 同目录 `references/known-conflicts.md` ＋ `references/capture-notes.md` | -> ⚠️ 路径怎么找，按两类分开写：本段**自带件**（`design-capture/`、`design-systems/`）写**段内相对路径**（`assets/design-systems/...`）；**同根技能**写 `<技能根>/<技能名>/`（`open-design` 用 `<技能根>/open-design/...`，`oil-ui-pro` 按技能名引用），与物理位置无关。⛔ 不按绝对路径爬、⛔ 不写死 `../` 层数（位置一变就失效且不报错）。 +> ⚠️ 路径怎么找，分三类写：**技能级工具箱**（`assets/design-capture/`、`assets/element-picker/`、`assets/diagram-design/`、`assets/video-capture/`，相对**本技能包根**，各段共用）；**本段自带资产**（`assets/design-systems/`，相对本段 `SKILL.md`）；**同根技能**写 `<技能根>/<技能名>/`（`open-design` 用 `<技能根>/open-design/...`，`oil-ui-pro` 按技能名引用）。⛔ 不按绝对路径爬、⛔ 不写死 `../` 层数（位置一变就失效且不报错）。 > 🔴 定调来源唯一：每次设计只选一套，默认与可选**不混用**（混用 = 没有调性）。套名与选择理由写进 `DESIGN.md`。 > ⛔ 判据正文仍只在本段（`references/execution-runbook.md` 与 `references/layouts-tooling.md`）。⚠️ 供给是分层的，分层定义见 §供给：`oil-ui-pro` 是**基础层**，本段自有判据是**叠加层**；同一条判据两处都有且口径不同时，⛔ 本段不许放宽基础层，只许更严、更具体，并在 runbook §3.4 标注「本项目追加」。 > ⛔ 不许把 `oil-ui-pro` 的评分循环当成 D 阶段的替代：它是评审方法，Gate-1/2/3 该过还得过。 > ⛔ 不动用可选来源时，⛔ 不许凭感觉编一套顶上（那正是本项目反复踩的坑）；craft 独有的那几项（反 AI 味 / 无障碍 / 表单校验 / 动效纪律）明说「本次无供给来源」。 > ⚠️ `oil-ui-pro` 自带联网版本检查与自动更新（每次使用会连 `ui.oiloil.org`，发现新版用 `npx` 覆盖自身目录）。这是本项目收录时用户明确要求全量搬入的例外项，与「依赖外部服务一律不收」的既有纪律冲突，记录在案，不扩散到其他技能。想关掉设环境变量 `OIL_NO_UPDATE_CHECK=1`。 -> 供给件都不依赖付费云 / MCP / API Key 才能用于设计：`open-design` 去掉那些之后剩下的全是静态 md / css / html（其 daemon、云模型服务、`packages/components` 的 tsx 未收录）；`oil-ui-pro` 的设计方法宿主中立、离线可用（联网仅用于版本检查）。 +> 供给件都不依赖付费云 / MCP / API Key 才能用于设计：`open-design` 去掉那些之后剩下的全是静态 md / css / html（其 daemon、云模型服务、`packages/components` 的 tsx 未收录）；`oil-ui-pro` 的设计方法**不依赖目标产品**、离线可用（联网仅用于版本检查）。 > 冲突处以 §供给·方法主线（基础层）为准；本段自有判据与 `DESIGN.md` 是叠加层，只许更严，⛔ 不许与基础层相反。供给件的价值在给正向目标、给方法。 > 为什么换掉原来的主干（2026-10-02 用户定案）：原主干 `ui-page-design` 已从磁盘移除，③段只剩规则壳，壳里又全是减法型判据，机检能判「不违规」却判不出「好看」，18 轮回改把页面越推越白。换供给的同时必须换判据结构：正向目标为主，禁令只留最关键的。 @@ -88,7 +88,7 @@ description: 产品规划第③段，界面交互。设计工程供给默认来 | ③段子步 | 做什么 | 产物 | 闸 | |---|---|---|---| | 3a 视觉规范 | 定契约（减法 + 加法）→ 定调（选定设计系统）→ 落令牌表〔方法主线按 `oil-ui-pro` 的方向探索走；要拉开方向让用户挑时用它的对比页〕 | 设计契约 + 令牌表 → `DESIGN.md` | Gate-1 方向门 | -| 3b 原型 | 按模板种子 + 版式骨架构建 | `docs/pm/<项目>/ui/<原型>.html` | — | +| 3b 原型 | 按模板种子 + 版式骨架构建 | `产品原型/designs/<原型>.html` | — | | 3c GPT 参考版 | 让 GPT 按需求＋风格**独立生成一版当参照物**（本段特有，两个设计技能都不覆盖） | `3c-GPT参考版.md` | — | | 3d 审查与打磨 | 收口 → 动效 → 终检〔按 `oil-ui-pro` 的评审协议做一轮独立评审打分〕 | file:line 清单 + `3d-审查报告.md` | Gate-2 / Gate-3 | @@ -123,6 +123,7 @@ description: 产品规划第③段，界面交互。设计工程供给默认来 > ⚠️ 3b 只取 §供给·版式骨架 的默认档。可选档那套（`web-prototype`）是营销落地页向，只在判「要不要套它的流程」时读。 > ⚠️ 本表只写「哪一步取哪个供给位」，⛔ 不写路径、不写默认判断 —— 那些只在 §供给 定义一次。 > 本段 `references/` 只放流程规则，⛔ 不放风格；随段携带的样式风格一律放 `assets/design-systems/<套>/`（🔴 2026-10-07 用户令两条：「把 `design-system-tiaoyue` 整合到 `product-planning` 作为一种样式风格」＋「后续可以添加多种风格，每次只能选择一种进行设计」⇒ 只把「不放风格」这条放宽到 `assets/`，`references/` 仍不放）。 +> ⚠️ `assets/design-systems/` 下的套**不入技能仓**（🔴 2026-10-16 用户令：`design-system-tiaoyue` 整个文件夹不提交，理由＝体积 14 MB 且可 CDP 重采）—— 新机器取仓后这一层是空的，属正常；要用自带套就按本文件 §供给 的说明另取，或按套内 `references/capture-notes.md` 重采。 > ⚠️ 续加新风格时的硬要求：目录名与可选档同形（`assets/design-systems/<套名>/`），套内自带入口文件（`SKILL.md` 或 `DESIGN.md`）；⛔ 不许改已入套的文件内容，原样搬入、只在本文件登记去向。 > 🔴 定调来源唯一（两档见 §供给·定调与令牌）：每次设计只选一套，⛔ 不许混用两档（混用 = 没有调性）。套名与选择理由写进 `DESIGN.md`。 > 既有项目中凡引用旧风格来源（`minimalist-ui` / 皮肤族 / `ui-ux-pro-max` 检索结果）的 `DESIGN.md` 行，重跑 3a 时一律改写为选定套 + 留痕对照。 @@ -154,7 +155,7 @@ D1 定调：从 §供给·定调与令牌 的默认档里选一套；要用可 - 产出令牌表：色值 / 字体（标题字体是关键项）/ 间距两档（主刻度 `4/8/16/24/32/64` 供布局 + 控件层微网格 `2/4/6/8/12` 仅供按钮内衬、徽章内衬、图标间隙、开关与进度轨微几何）/ 圆角 / 字阶定值表（七档各一个 px，不是区间）/ 高度层级（每层都有多层叠层值）/ 布局脚手架（骨架档落到具体列宽 + 窄屏变化）/ 组件规格（按钮三档 + 卡片两档 + 输入框 + 徽章的具体高度与内衬；实底底色 ≥2 种）/ 动效基调——全部为具体值，禁止「待定」，每档只许一个定值 -落盘 `docs/pm/<项目>/DESIGN.md`：令牌表内容并入本项目既有的三层 token 结构（primitive → semantic → component；组件只引语义层、语义层只引 primitive），设计契约作首节。`DESIGN.md` 是原型的绑定规范，原型只许引它的 token。 +落盘 `产品原型/designs/DESIGN.md`：令牌表内容并入本项目既有的三层 token 结构（primitive → semantic → component；组件只引语义层、语义层只引 primitive），设计契约作首节。`DESIGN.md` 是原型的绑定规范，原型只许引它的 token。 Gate-1 方向门（硬闸，不可跳）——按本表逐项自检（字段定义与填写位见 `references/execution-runbook.md` §2.1；⛔ 供给件没这一项，十二字段只能在此判）： @@ -194,14 +195,17 @@ Gate-1 方向门（硬闸，不可跳）——按本表逐项自检（字段定 ⚠️ 两份工具型文件的分工（2026-10-05 补）：本技能 `references/layouts-tooling.md` 给可粘贴 HTML 骨架 + 逐条判据正文（§5.5），是默认档；选了可选档时，它那份 `tooling.md` 另给四形态判定句 + 通用红线纲要，只作指路。⛔ 判据只在 `layouts-tooling.md` 展开，`tooling.md` 只指路，两处展开必然漂。 形态判定一句话：页面上能数出「并列的同类记录」⇒ 列表型（工具型默认首选）；数不出、页面围绕单个对象展开 ⇒ 详情型；主操作要在两个工作面之间来回 ⇒ 侧区型。 ⛔ 不许拿营销页骨架顶替工具型，那是「没做形态判定」的默认行为，等于退回 18 轮前的病根。判不出形态就去改 D0 的 `结构骨架` 字段，⛔ 不许随手挑一个。 -- 不许从零手写 `
`：先挑最接近的骨架粘进去再改。用了可选档时，可选档那套的 `layouts.md` 开头的类清单（`section` / `container` / `card` / `btn-primary` / `grid-3` …）必须在种子 `template.html` 的 ` - - - -
-
-

跳跃视界

跳跃视界是 AI 创作平台，支持 AI 短剧、AI 漫剧、AI 短视频与 AI 视频一站式生成。创意对话、一键成片、画布创作、资产调用，全程可控。

www.tiaoyue.com ↗
- Captured -
-
跳跃视界
-
-

标志

Brand mark
-

字体

Ag
PingFang SC
Display
Ag
PingFang SC
Body
Ag
PingFang SC
Mono
DisplayPingFang SC · 400

跳跃视界

BodyPingFang SC · 400

跳跃视界是 AI 创作平台，支持 AI 短剧、AI 漫剧、AI 短视频与 AI 视频一站式生成。创意对话、一键成片、画布创作、资产调用，全程可控。

MonoPingFang SC · 400

const system = capture(url)

-
-

色板

#FFFFFF
背景
background
Page background
#FFFFFF
表面
surface
Cards and raised panels
#000000
前景
foreground
Primary text and icons
#A1A1AA
弱化
muted
Secondary text and captions
#E5E7EB
边框
border
Dividers and outlines
#9E4CFF
强调
accent
Primary actions and emphasis
#FED7AA
辅助
accent-secondary
Secondary highlights
#C4B5FD
高亮
highlight
Accents and details
-
-

Voice & tone

跳跃视界跳跃世界AI短剧AI漫剧AI短视频AI视频AI创作平台一键成片

跳跃视界是 AI 创作平台，支持 AI 短剧、AI 漫剧、AI 短视频与 AI 视频一站式生成。创意对话、一键成片、画布创作、资产调用，全程可控。

  • —全域闭环 化繁为简
  • —发现新版本
  • —通知
-

Imagery & layout

15 representative images captured from this page.

Subjects: 跳跃视界, 跳跃世界, AI短剧, AI漫剧, AI短视频, AI视频

Corner radius: 24px

Layout posture
  • Rounded corners (~24px radius)
  • Soft shadows add depth
  • Hairline borders frame content
-
-

图片

-

组件套件

Buttons, inputs and cards rebuilt from this site's own component styles — radius, padding, border, shadow, weight and color.

-
-
Buttons
-
- - - - - - - - - -
-
-
-
Inputs
-
- - - - -
- - -
-
-
Selection
-
- - - - Enabled - -
-
-
-
Badges & tags
-
- New - Beta - Pro - Active - Overview× - Activity× - Hover meTooltip -
-
-
-
Avatars
-
- ATGH+5 - ALAda LovelaceOverview -
-
-
-
Navigation
-
- -
-
1Account2Details3Done
-
-
-
-
-
Data display
-
-
Visitors128.4k+12.5%
-
Revenue$48,920+4.2%
-
Churn1.8%-0.4%
-
- - - -
NameRoleStatus
ALAda LovelaceOverviewActive
ATAlan TuringActivityPending
-
    -
  • 全域闭环 化繁为简Updated just nowNew
    • -
  • 发现新版本Updated just now›
    • -
-
-
-
Feedback
-
★Heads up — this kit is generated from one captured design seed.
-
SavedYour changes are live.×
-
-
-
-
-
Card title
-

Cards, fields and chips inherit the captured radius, border and color.

-
-
-
-
Overview⌘O
-
Activity⌘A
-
-
Settings
-
-
-
-
Overlays
-
-
Delete item?×
-

This action cannot be undone. The item will be permanently removed.

-
-
-
-
-

Templates

Ready-made layouts — landing, deck, poster, email, newsletter and form — composed from this brand. Click any tile to preview the full page.

-

此文件在 #od-design-system-data 中包含结构化 JSON，供后续自动化使用。

-
- - - - \ No newline at end of file diff --git a/product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/references/known-conflicts.md b/product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/references/known-conflicts.md deleted file mode 100644 index f36d2a3..0000000 --- a/product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/references/known-conflicts.md +++ /dev/null @@ -1,82 +0,0 @@ -# 已知冲突登记（design-system-tiaoyue） - -> ⛔ **本文件只登记"挖出来但未裁决"的冲突**，每条必须写全：现象 / 两条独立证据 / -> 为什么现在不裁决 / 裁决前⛔ 怎么用。 -> ⛔ **禁止**在本文件里"顺手 harmonize"—— 冲突没裁决就合并，等于把不确定变成看起来确定。 -> -> 登记时间：2026-10-05（暗色补抓并入时） - ---- - -## C-01 · 亮色基线存在**两套**，暗色与亮色是否同源未证 - -**状态**：🟡 **已裁决「不混搭」部分**（2026-10-05，棒2 独立复核 `_c01_recheck.py`： -6 角色 5 条不同、色温相反 A 暖 5/5 vs B 冷 3/5、跨路混搭对比度全达标故须结构约定防住） -**裁决内容**：暗色与亮色是两套独立基线，不共用令牌；要暗色就整套切。 -⛔ 仍**未裁决**：哪一套亮色才是 tiaoyue 主线的正解（A 路 or B 路）—— - 这一条要**在主线页面**（⛔ 非 team 页）同批抓一次 light+dark 才能定， - 需要动技能之外的抓取动作，棒2 ⛔ 未做（域外 + 需批准）。 - -### 现象 - -同一个站（tiaoyue.com）的亮色形态，两次独立抓取给出**两套不同的值**： - -| 角色 | A 路：clipper 9 页（= `assets/tokens.css`） | B 路：CDP 活动页 DOM（暗色补抓同批读出） | 是否相同 | -|---|---|---|---| -| background | `#faf9f5`（暖白纸感） | `#f2f2f2`（冷灰） | ❌ | -| foreground | `#1a1a18` | `#000000` | ❌ | -| muted | `#57564f` | `#52525b` | ❌ | -| faint | `#8a887f` | `#71717a` | ❌ | -| border | `#e7e5dc`（暖调） | `#f4f4f5`（冷调） | ❌ | -| surface | `#ffffff` | `#ffffff` | ✅ | -| **accent** | `#9E4CFF` | `#9e4cff` | ✅ **唯一恒定** | - -⚠️ 注意 A 路整体偏**暖**（`#faf9f5`/`#e7e5dc`/`#57564f`），B 路整体偏**冷**（`#f2f2f2`/`#f4f4f5`/`#52525b`）。 -这不是零散漂移，是**两套色温不同的体系**。 - -### 两条独立证据（为什么确信"真的有两套"，不是某一次读错） - -1. **A 路**：`assets/brand.json` + `assets/tokens.css`，来源 `open-design clipper`，`extractedAt: 2026-10-05`， - 覆盖 9 个登录后页面。 -2. **B 路**：`_probe_raw.json` + `tokens-dark.css`，来源 CDP `getComputedStyle(document.documentElement)`， - 覆盖 1 个页面（`/team/onboarding`）。**同一次请求里同时切了 dark/light 两种属性**， - 变异对照有效（`data-theme` 回读值随请求变）⇒ B 路的 light/dark 读数本身可信。 - -⚠️ **但两条证据各自都有可疑之处，这正是不能立刻裁决的原因**： -- A 路的 clipper 抓的是**渲染态**；源站默认 `dark`（首页首帧脚本自证），若clipper 抓到的其实是 - 暗色渲染结果再"反推"成亮色，整套值就不可信。 -- B 路只覆盖**活动页**一个页面，而该页正是 `SKILL.md` §0 明令**生成时避开**的 team 页。 - ⛔ 用一个"该避开的页面"的值去定义全站亮色，本身就可能不代表主线页面。 - -### 为什么现在不裁决 - -裁决需要**在主线页面上同批抓一次 light+dark**（一次会话、一个 profile、同一批 `getComputedStyle`）， -才能得到真正可比的 A/B。本棒⛔ 没有做（且改技能应先于重跑页面，不能在未定的判据上跑页面）。 - -### 裁决前 ⛔ 怎么用（硬规则） - -1. **要暗色 ⇒ 整套切**：`tokens-dark.css` ＋ B 路亮色值，⛔ 不要与 `tokens.css` 混搭。 -2. **⛔ 不要**把 `tokens.css` 亮色 + `tokens-dark.css` 暗色合成一套上生产 —— 那是本冲突的产物， - 不是解法。 -3. 本文件里 `tokens-dark.css` 的暗色值**本身可信**（实测 + 两条链路互证）， - 可单独使用；⛔ 不可信的只是"它与 `tokens.css` 亮色配对"这个假设。 - -### 裁决它需要做的最小动作 - -- 在**主线页面**（如首页/ 资产页，⛔ 非 team 页）用同一探针切`light`/`dark` 各读一次， - 与现有两套值并排比对； -- 顺带查清clipper 那次抓的到底是亮色还是暗色渲染态（决定 A 路要不要整体作废）。 - ---- - -## C-02 · `on-accent` 对 `accent` 只有 4.26:1（两形态一致） - -**状态**：🟡 已登记，处置方式已定 - -**现象**：`#FFFFFF` / `#9e4cff` = **4.26:1**，低于正文 4.5:1，**亮暗两形态完全相同** -⇒ 这是品牌紫的固有属性，**⛔ 不是暗色引入的新问题**，调暗色解决不了它。 - -**已定处置**（实测过候选，见下）： -- 主按钮文字用 **≥16px + bold** ⇒ 走大字线 **3:1**，4.26 ✅ 通过； -- ⛔ 若要小字（<16px 常规字重）压在主色上，⛔ 本规范**不提供**合规解 - （试过 `#1a0a2e` = 4.38，⛔ 仍不过 4.5）⇒ 这种情况不许出现。 diff --git a/product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/references/library.json b/product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/references/library.json deleted file mode 100644 index c99be21..0000000 --- a/product-planning/references/stage-delivery/assets/design-systems/design-system-tiaoyue/references/library.json +++ /dev/null @@ -1,4113 +0,0 @@ -{ - "source": "https://www.tiaoyue.com/", - "pages": { - "home": { - "cn": "首页", - "total": 611, - "own": 252, - "families": 101 - }, - "drama": { - "cn": "影视", - "total": 515, - "own": 241, - "families": 148 - }, - "shortvideo": { - "cn": "短视频", - "total": 669, - "own": 308, - "families": 193 - }, - "redraw": { - "cn": "转绘", - "total": 515, - "own": 241, - "families": 148 - }, - "canvas": { - "cn": "画布", - "total": 436, - "own": 163, - "families": 73 - }, - "script": { - "cn": "剧本", - "total": 684, - "own": 190, - "families": 93 - }, - "asset": { - "cn": "资产", - "total": 572, - "own": 253, - "families": 97 - }, - "space": { - "cn": "空间", - "total": 562, - "own": 202, - "families": 91 - }, - "team": { - "cn": "团队", - "total": 465, - "own": 169, - "families": 77 - } - }, - "skipOnGenerate": [ - "team" - ], - "summary": { - "ownFamilies": 277, - "elementPlus": 52, - "tailwind": 659 - }, - "families": { - "double-festival-card": { - "totalUsage": 99, - "pageCount": 9, - "pages": { - "home": 11, - "drama": 11, - "shortvideo": 11, - "redraw": 11, - "canvas": 11, - "script": 11, - "asset": 11, - "space": 11, - "team": 11 - }, - "members": { - "double-festival-card": 9, - "double-festival-card__hero": 9, - "double-festival-card__content": 9, - "double-festival-card__logo": 9, - "double-festival-card__heading": 9, - "double-festival-card__eyebrow": 9, - "double-festival-card__title": 9, - "double-festival-card__offer": 9, - "double-festival-card__benefits": 9, - "double-festival-card__action": 9, - "double-festival-card__action-arrow": 9 - }, - "teamOnly": false - }, - "nav-tips": { - "totalUsage": 90, - "pageCount": 9, - "pages": { - "home": 10, - "drama": 10, - "shortvideo": 10, - "redraw": 10, - "canvas": 10, - "script": 10, - "asset": 10, - "space": 10, - "team": 10 - }, - "members": { - "nav-tips__row": 81, - "nav-tips": 9 - }, - "teamOnly": false - }, - "nav-item": { - "totalUsage": 81, - "pageCount": 9, - "pages": { - "home": 9, - "drama": 9, - "shortvideo": 9, - "redraw": 9, - "canvas": 9, - "script": 9, - "asset": 9, - "space": 9, - "team": 9 - }, - "members": { - "nav-item": 81 - }, - "teamOnly": false - }, - "nav-icon": { - "totalUsage": 81, - "pageCount": 9, - "pages": { - "home": 9, - "drama": 9, - "shortvideo": 9, - "redraw": 9, - "canvas": 9, - "script": 9, - "asset": 9, - "space": 9, - "team": 9 - }, - "members": { - "nav-icon": 81 - }, - "teamOnly": false - }, - "nav-tip": { - "totalUsage": 81, - "pageCount": 9, - "pages": { - "home": 9, - "drama": 9, - "shortvideo": 9, - "redraw": 9, - "canvas": 9, - "script": 9, - "asset": 9, - "space": 9, - "team": 9 - }, - "members": { - "nav-tip": 81 - }, - "teamOnly": false - }, - "menu-item": { - "totalUsage": 81, - "pageCount": 9, - "pages": { - "home": 9, - "drama": 9, - "shortvideo": 9, - "redraw": 9, - "canvas": 9, - "script": 9, - "asset": 9, - "space": 9, - "team": 9 - }, - "members": { - "menu-item__label": 72, - "menu-item__badge": 9 - }, - "teamOnly": false - }, - "maiya-btn": { - "totalUsage": 78, - "pageCount": 9, - "pages": { - "home": 6, - "drama": 6, - "shortvideo": 12, - "redraw": 6, - "canvas": 6, - "script": 6, - "asset": 6, - "space": 21, - "team": 9 - }, - "members": { - "maiya-btn__label": 26, - "maiya-btn--size-md": 21, - "maiya-btn--primary": 11, - "maiya-btn--secondaryWeak": 9, - "maiya-btn--size-space": 5, - "maiya-btn--glass": 4, - "maiya-btn--tertiary": 2 - }, - "teamOnly": false - }, - "is-inactive": { - "totalUsage": 72, - "pageCount": 9, - "pages": { - "home": 8, - "drama": 8, - "shortvideo": 8, - "redraw": 8, - "canvas": 8, - "script": 8, - "asset": 8, - "space": 8, - "team": 8 - }, - "members": { - "is-inactive": 72 - }, - "teamOnly": false - }, - "is-light": { - "totalUsage": 69, - "pageCount": 9, - "pages": { - "home": 6, - "drama": 6, - "shortvideo": 10, - "redraw": 6, - "canvas": 6, - "script": 12, - "asset": 10, - "space": 7, - "team": 6 - }, - "members": { - "is-light": 69 - }, - "teamOnly": false - }, - "deployment-update-notice": { - "totalUsage": 54, - "pageCount": 9, - "pages": { - "home": 6, - "drama": 6, - "shortvideo": 6, - "redraw": 6, - "canvas": 6, - "script": 6, - "asset": 6, - "space": 6, - "team": 6 - }, - "members": { - "deployment-update-notice": 9, - "deployment-update-notice__panel": 9, - "deployment-update-notice__icon": 9, - "deployment-update-notice__badge": 9, - "deployment-update-notice__close": 9, - "deployment-update-notice__actions": 9 - }, - "teamOnly": false - }, - "auth-field": { - "totalUsage": 54, - "pageCount": 9, - "pages": { - "home": 6, - "drama": 6, - "shortvideo": 6, - "redraw": 6, - "canvas": 6, - "script": 6, - "asset": 6, - "space": 6, - "team": 6 - }, - "members": { - "auth-field": 54 - }, - "teamOnly": false - }, - "auth-agreement-link": { - "totalUsage": 54, - "pageCount": 9, - "pages": { - "home": 6, - "drama": 6, - "shortvideo": 6, - "redraw": 6, - "canvas": 6, - "script": 6, - "asset": 6, - "space": 6, - "team": 6 - }, - "members": { - "auth-agreement-link": 54 - }, - "teamOnly": false - }, - "header-action-btn": { - "totalUsage": 37, - "pageCount": 9, - "pages": { - "home": 5, - "drama": 4, - "shortvideo": 4, - "redraw": 4, - "canvas": 4, - "script": 4, - "asset": 4, - "space": 4, - "team": 4 - }, - "members": { - "header-action-btn--text": 27, - "header-action-btn--icon": 10 - }, - "teamOnly": false - }, - "course-entry": { - "totalUsage": 36, - "pageCount": 9, - "pages": { - "home": 4, - "drama": 4, - "shortvideo": 4, - "redraw": 4, - "canvas": 4, - "script": 4, - "asset": 4, - "space": 4, - "team": 4 - }, - "members": { - "course-entry": 9, - "course-entry__hover-bg": 9, - "course-entry__details": 9, - "course-entry__badge": 9 - }, - "teamOnly": false - }, - "points-capsule": { - "totalUsage": 36, - "pageCount": 9, - "pages": { - "home": 4, - "drama": 4, - "shortvideo": 4, - "redraw": 4, - "canvas": 4, - "script": 4, - "asset": 4, - "space": 4, - "team": 4 - }, - "members": { - "points-capsule--single": 9, - "points-capsule__section": 9, - "points-capsule__interactive": 9, - "points-capsule__points": 9 - }, - "teamOnly": false - }, - "beta-code-panel": { - "totalUsage": 27, - "pageCount": 9, - "pages": { - "home": 3, - "drama": 3, - "shortvideo": 3, - "redraw": 3, - "canvas": 3, - "script": 3, - "asset": 3, - "space": 3, - "team": 3 - }, - "members": { - "beta-code-panel": 18, - "beta-code-panel--white": 9 - }, - "teamOnly": false - }, - "notice-tabs": { - "totalUsage": 27, - "pageCount": 9, - "pages": { - "home": 3, - "drama": 3, - "shortvideo": 3, - "redraw": 3, - "canvas": 3, - "script": 3, - "asset": 3, - "space": 3, - "team": 3 - }, - "members": { - "notice-tabs__item": 18, - "notice-tabs__badge": 9 - }, - "teamOnly": false - }, - "is-active": { - "totalUsage": 23, - "pageCount": 9, - "pages": { - "home": 3, - "drama": 2, - "shortvideo": 4, - "redraw": 2, - "canvas": 2, - "script": 2, - "asset": 2, - "space": 4, - "team": 2 - }, - "members": { - "is-active": 23 - }, - "teamOnly": false - }, - "avatar-personal": { - "totalUsage": 18, - "pageCount": 9, - "pages": { - "home": 2, - "drama": 2, - "shortvideo": 2, - "redraw": 2, - "canvas": 2, - "script": 2, - "asset": 2, - "space": 2, - "team": 2 - }, - "members": { - "avatar-personal": 18 - }, - "teamOnly": false - }, - "beta-code-popper": { - "totalUsage": 18, - "pageCount": 9, - "pages": { - "home": 2, - "drama": 2, - "shortvideo": 2, - "redraw": 2, - "canvas": 2, - "script": 2, - "asset": 2, - "space": 2, - "team": 2 - }, - "members": { - "beta-code-popper": 18 - }, - "teamOnly": false - }, - "auth-dialog-overlay": { - "totalUsage": 18, - "pageCount": 9, - "pages": { - "home": 2, - "drama": 2, - "shortvideo": 2, - "redraw": 2, - "canvas": 2, - "script": 2, - "asset": 2, - "space": 2, - "team": 2 - }, - "members": { - "auth-dialog-overlay": 18 - }, - "teamOnly": false - }, - "is-align-center": { - "totalUsage": 18, - "pageCount": 9, - "pages": { - "home": 2, - "drama": 2, - "shortvideo": 2, - "redraw": 2, - "canvas": 2, - "script": 2, - "asset": 2, - "space": 2, - "team": 2 - }, - "members": { - "is-align-center": 18 - }, - "teamOnly": false - }, - "auth-tab": { - "totalUsage": 18, - "pageCount": 9, - "pages": { - "home": 2, - "drama": 2, - "shortvideo": 2, - "redraw": 2, - "canvas": 2, - "script": 2, - "asset": 2, - "space": 2, - "team": 2 - }, - "members": { - "auth-tab": 18 - }, - "teamOnly": false - }, - "auth-submit-btn": { - "totalUsage": 18, - "pageCount": 9, - "pages": { - "home": 2, - "drama": 2, - "shortvideo": 2, - "redraw": 2, - "canvas": 2, - "script": 2, - "asset": 2, - "space": 2, - "team": 2 - }, - "members": { - "auth-submit-btn": 18 - }, - "teamOnly": false - }, - "auth-agreement-text": { - "totalUsage": 18, - "pageCount": 9, - "pages": { - "home": 2, - "drama": 2, - "shortvideo": 2, - "redraw": 2, - "canvas": 2, - "script": 2, - "asset": 2, - "space": 2, - "team": 2 - }, - "members": { - "auth-agreement-text": 18 - }, - "teamOnly": false - }, - "double-festival-shell": { - "totalUsage": 18, - "pageCount": 9, - "pages": { - "home": 2, - "drama": 2, - "shortvideo": 2, - "redraw": 2, - "canvas": 2, - "script": 2, - "asset": 2, - "space": 2, - "team": 2 - }, - "members": { - "double-festival-shell": 9, - "double-festival-shell__close": 9 - }, - "teamOnly": false - }, - "app-bg": { - "totalUsage": 13, - "pageCount": 9, - "pages": { - "home": 2, - "drama": 2, - "shortvideo": 2, - "redraw": 2, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "app-bg": 9, - "app-bg--creative-workbench": 3, - "app-bg--home": 1 - }, - "teamOnly": false - }, - "layout-main": { - "totalUsage": 10, - "pageCount": 9, - "pages": { - "home": 2, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "layout-main": 9, - "layout-main--no-scrollbar": 1 - }, - "teamOnly": false - }, - "is-disabled": { - "totalUsage": 10, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 2, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "is-disabled": 10 - }, - "teamOnly": false - }, - "-bottom-px": { - "totalUsage": 10, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 2, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "-bottom-px": 10 - }, - "teamOnly": false - }, - "vjs-styles-defaults": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "vjs-styles-defaults": 9 - }, - "teamOnly": false - }, - "-z-10": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "-z-10": 9 - }, - "teamOnly": false - }, - "sidebar-shell": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "sidebar-shell": 9 - }, - "teamOnly": false - }, - "app-sidebar": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "app-sidebar": 9 - }, - "teamOnly": false - }, - "nav-tips-layer": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "nav-tips-layer": 9 - }, - "teamOnly": false - }, - "nav-tips-viewport": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "nav-tips-viewport": 9 - }, - "teamOnly": false - }, - "is-visible": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "is-visible": 9 - }, - "teamOnly": false - }, - "is-expand-right": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "is-expand-right": 9 - }, - "teamOnly": false - }, - "-top-1.5": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "-top-1.5": 9 - }, - "teamOnly": false - }, - "layout-header": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "layout-header": 9 - }, - "teamOnly": false - }, - "-mr-10": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "-mr-10": 9 - }, - "teamOnly": false - }, - "router-link-active": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "router-link-active": 9 - }, - "teamOnly": false - }, - "notification-trigger": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "notification-trigger__badge": 9 - }, - "teamOnly": false - }, - "is-fixed": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "is-fixed": 9 - }, - "teamOnly": false - }, - "is-dot": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "is-dot": 9 - }, - "teamOnly": false - }, - "header-avatar-btn": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "header-avatar-btn__fallback": 9 - }, - "teamOnly": false - }, - "course-qr-panel": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "course-qr-panel": 9 - }, - "teamOnly": false - }, - "points-balance-popover": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "points-balance-popover__total": 9 - }, - "teamOnly": false - }, - "user-menu-popper": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "user-menu-popper": 9 - }, - "teamOnly": false - }, - "user-panel": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "user-panel": 9 - }, - "teamOnly": false - }, - "switch-identity-btn": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "switch-identity-btn": 9 - }, - "teamOnly": false - }, - "auth-dialog": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "auth-dialog": 9 - }, - "teamOnly": false - }, - "auth-card": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "auth-card": 9 - }, - "teamOnly": false - }, - "auth-code-btn": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "auth-code-btn": 9 - }, - "teamOnly": false - }, - "auth-agreement-check": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "auth-agreement-check": 9 - }, - "teamOnly": false - }, - "create-team-modal": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "create-team-modal": 9 - }, - "teamOnly": false - }, - "referral-modal": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "referral-modal": 9 - }, - "teamOnly": false - }, - "referral-qr-modal": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "referral-qr-modal": 9 - }, - "teamOnly": false - }, - "feedback-modal": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "feedback-modal": 9 - }, - "teamOnly": false - }, - "is-drawer": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "is-drawer": 9 - }, - "teamOnly": false - }, - "account-settings-modal": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "account-settings-modal": 9 - }, - "teamOnly": false - }, - "account-settings-drawer": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "account-settings-drawer": 9 - }, - "teamOnly": false - }, - "rtl": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "rtl": 9 - }, - "teamOnly": false - }, - "switch-identity-modal": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "switch-identity-modal": 9 - }, - "teamOnly": false - }, - "contact-modal": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "contact-modal": 9 - }, - "teamOnly": false - }, - "business-cooperation-modal": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "business-cooperation-modal": 9 - }, - "teamOnly": false - }, - "double-festival-modal": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "double-festival-modal": 9 - }, - "teamOnly": false - }, - "double-festival-dialog": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "double-festival-dialog": 9 - }, - "teamOnly": false - }, - "tenant-switch-modal": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "tenant-switch-modal": 9 - }, - "teamOnly": false - }, - "asset-picker-sdk-overlay": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "asset-picker-sdk-overlay": 9 - }, - "teamOnly": false - }, - "asset-picker-sdk-frame": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "asset-picker-sdk-frame": 9 - }, - "teamOnly": false - }, - "is-ready": { - "totalUsage": 9, - "pageCount": 9, - "pages": { - "home": 1, - "drama": 1, - "shortvideo": 1, - "redraw": 1, - "canvas": 1, - "script": 1, - "asset": 1, - "space": 1, - "team": 1 - }, - "members": { - "is-ready": 9 - }, - "teamOnly": false - }, - "is-pure": { - "totalUsage": 13, - "pageCount": 4, - "pages": { - "shortvideo": 2, - "script": 6, - "asset": 4, - "space": 1 - }, - "members": { - "is-pure": 13 - }, - "teamOnly": false - }, - "is-horizontal": { - "totalUsage": 13, - "pageCount": 4, - "pages": { - "shortvideo": 2, - "script": 6, - "asset": 4, - "space": 1 - }, - "members": { - "is-horizontal": 13 - }, - "teamOnly": false - }, - "is-vertical": { - "totalUsage": 13, - "pageCount": 4, - "pages": { - "shortvideo": 2, - "script": 6, - "asset": 4, - "space": 1 - }, - "members": { - "is-vertical": 13 - }, - "teamOnly": false - }, - "dramaHomeSkeletonShimmer": { - "totalUsage": 126, - "pageCount": 3, - "pages": { - "drama": 42, - "shortvideo": 42, - "redraw": 42 - }, - "members": { - "dramaHomeSkeletonShimmer": 126 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectLine": { - "totalUsage": 54, - "pageCount": 3, - "pages": { - "drama": 18, - "shortvideo": 18, - "redraw": 18 - }, - "members": { - "dramaHomeSkeletonProjectLine": 54 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectCoverGlow": { - "totalUsage": 36, - "pageCount": 3, - "pages": { - "drama": 12, - "shortvideo": 12, - "redraw": 12 - }, - "members": { - "dramaHomeSkeletonProjectCoverGlow": 36 - }, - "teamOnly": false - }, - "dramaHomeSkeletonViralLine": { - "totalUsage": 30, - "pageCount": 3, - "pages": { - "drama": 10, - "shortvideo": 10, - "redraw": 10 - }, - "members": { - "dramaHomeSkeletonViralLine": 30 - }, - "teamOnly": false - }, - "dramaHomeSkeletonViralTab": { - "totalUsage": 24, - "pageCount": 3, - "pages": { - "drama": 8, - "shortvideo": 8, - "redraw": 8 - }, - "members": { - "dramaHomeSkeletonViralTab": 24 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectCard": { - "totalUsage": 18, - "pageCount": 3, - "pages": { - "drama": 6, - "shortvideo": 6, - "redraw": 6 - }, - "members": { - "dramaHomeSkeletonProjectCard": 18 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectCardInner": { - "totalUsage": 18, - "pageCount": 3, - "pages": { - "drama": 6, - "shortvideo": 6, - "redraw": 6 - }, - "members": { - "dramaHomeSkeletonProjectCardInner": 18 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectCoverShell": { - "totalUsage": 18, - "pageCount": 3, - "pages": { - "drama": 6, - "shortvideo": 6, - "redraw": 6 - }, - "members": { - "dramaHomeSkeletonProjectCoverShell": 18 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectCover": { - "totalUsage": 18, - "pageCount": 3, - "pages": { - "drama": 6, - "shortvideo": 6, - "redraw": 6 - }, - "members": { - "dramaHomeSkeletonProjectCover": 18 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectCoverGlowOrange": { - "totalUsage": 18, - "pageCount": 3, - "pages": { - "drama": 6, - "shortvideo": 6, - "redraw": 6 - }, - "members": { - "dramaHomeSkeletonProjectCoverGlowOrange": 18 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectCoverGlowBlue": { - "totalUsage": 18, - "pageCount": 3, - "pages": { - "drama": 6, - "shortvideo": 6, - "redraw": 6 - }, - "members": { - "dramaHomeSkeletonProjectCoverGlowBlue": 18 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectCoverSparkle": { - "totalUsage": 18, - "pageCount": 3, - "pages": { - "drama": 6, - "shortvideo": 6, - "redraw": 6 - }, - "members": { - "dramaHomeSkeletonProjectCoverSparkle": 18 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectInfo": { - "totalUsage": 18, - "pageCount": 3, - "pages": { - "drama": 6, - "shortvideo": 6, - "redraw": 6 - }, - "members": { - "dramaHomeSkeletonProjectInfo": 18 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectLineTitle": { - "totalUsage": 18, - "pageCount": 3, - "pages": { - "drama": 6, - "shortvideo": 6, - "redraw": 6 - }, - "members": { - "dramaHomeSkeletonProjectLineTitle": 18 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectLineCapsule": { - "totalUsage": 18, - "pageCount": 3, - "pages": { - "drama": 6, - "shortvideo": 6, - "redraw": 6 - }, - "members": { - "dramaHomeSkeletonProjectLineCapsule": 18 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectLineMeta": { - "totalUsage": 18, - "pageCount": 3, - "pages": { - "drama": 6, - "shortvideo": 6, - "redraw": 6 - }, - "members": { - "dramaHomeSkeletonProjectLineMeta": 18 - }, - "teamOnly": false - }, - "dhsRedrawShimmer": { - "totalUsage": 15, - "pageCount": 3, - "pages": { - "drama": 5, - "shortvideo": 5, - "redraw": 5 - }, - "members": { - "dhsRedrawShimmer": 15 - }, - "teamOnly": false - }, - "dramaHomeSkeletonViralCard": { - "totalUsage": 15, - "pageCount": 3, - "pages": { - "drama": 5, - "shortvideo": 5, - "redraw": 5 - }, - "members": { - "dramaHomeSkeletonViralCard": 15 - }, - "teamOnly": false - }, - "dramaHomeSkeletonViralCover": { - "totalUsage": 15, - "pageCount": 3, - "pages": { - "drama": 5, - "shortvideo": 5, - "redraw": 5 - }, - "members": { - "dramaHomeSkeletonViralCover": 15 - }, - "teamOnly": false - }, - "dramaHomeSkeletonViralInfo": { - "totalUsage": 15, - "pageCount": 3, - "pages": { - "drama": 5, - "shortvideo": 5, - "redraw": 5 - }, - "members": { - "dramaHomeSkeletonViralInfo": 15 - }, - "teamOnly": false - }, - "dramaHomeSkeletonViralLineTitle": { - "totalUsage": 15, - "pageCount": 3, - "pages": { - "drama": 5, - "shortvideo": 5, - "redraw": 5 - }, - "members": { - "dramaHomeSkeletonViralLineTitle": 15 - }, - "teamOnly": false - }, - "dramaHomeSkeletonViralLineDesc": { - "totalUsage": 15, - "pageCount": 3, - "pages": { - "drama": 5, - "shortvideo": 5, - "redraw": 5 - }, - "members": { - "dramaHomeSkeletonViralLineDesc": 15 - }, - "teamOnly": false - }, - "creationWorkbenchTab": { - "totalUsage": 9, - "pageCount": 3, - "pages": { - "drama": 3, - "shortvideo": 3, - "redraw": 3 - }, - "members": { - "creationWorkbenchTab": 9 - }, - "teamOnly": false - }, - "creationWorkbenchTabIcon": { - "totalUsage": 9, - "pageCount": 3, - "pages": { - "drama": 3, - "shortvideo": 3, - "redraw": 3 - }, - "members": { - "creationWorkbenchTabIcon": 9 - }, - "teamOnly": false - }, - "dhsRedrawMeasure": { - "totalUsage": 9, - "pageCount": 3, - "pages": { - "drama": 3, - "shortvideo": 3, - "redraw": 3 - }, - "members": { - "dhsRedrawMeasure": 9 - }, - "teamOnly": false - }, - "dhsRedrawFill": { - "totalUsage": 9, - "pageCount": 3, - "pages": { - "drama": 3, - "shortvideo": 3, - "redraw": 3 - }, - "members": { - "dhsRedrawFill": 9 - }, - "teamOnly": false - }, - "dhsRedrawCard": { - "totalUsage": 9, - "pageCount": 3, - "pages": { - "drama": 3, - "shortvideo": 3, - "redraw": 3 - }, - "members": { - "dhsRedrawCard": 9 - }, - "teamOnly": false - }, - "creationWorkbench": { - "totalUsage": 7, - "pageCount": 3, - "pages": { - "drama": 3, - "shortvideo": 1, - "redraw": 3 - }, - "members": { - "creationWorkbench": 3, - "creationWorkbench--studio": 2, - "creationWorkbench--hostBodyScroll": 2 - }, - "teamOnly": false - }, - "dhsRedrawPill": { - "totalUsage": 6, - "pageCount": 3, - "pages": { - "drama": 2, - "shortvideo": 2, - "redraw": 2 - }, - "members": { - "dhsRedrawPill": 6 - }, - "teamOnly": false - }, - "creativeAurora": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "creativeAurora": 3 - }, - "teamOnly": false - }, - "creativeAuroraGlow": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "creativeAuroraGlow": 3 - }, - "teamOnly": false - }, - "creationWorkbenchTabsBar": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "creationWorkbenchTabsBar": 3 - }, - "teamOnly": false - }, - "creationWorkbenchTabs": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "creationWorkbenchTabs": 3 - }, - "teamOnly": false - }, - "creationWorkbenchTabActive": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "creationWorkbenchTabActive": 3 - }, - "teamOnly": false - }, - "creationWorkbenchDramaSlot": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "creationWorkbenchDramaSlot": 3 - }, - "teamOnly": false - }, - "dramaWujieHost": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaWujieHost": 3 - }, - "teamOnly": false - }, - "dramaWujieHostEmbedded": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaWujieHostEmbedded": 3 - }, - "teamOnly": false - }, - "dramaWujieHostHostBodyScroll": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaWujieHostHostBodyScroll": 3 - }, - "teamOnly": false - }, - "dramaWujieHostMaskIframeUntilReady": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaWujieHostMaskIframeUntilReady": 3 - }, - "teamOnly": false - }, - "dramaSubAppLoadingShell": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaSubAppLoadingShell": 3 - }, - "teamOnly": false - }, - "dramaSubAppLoadingShellFlow": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaSubAppLoadingShellFlow": 3 - }, - "teamOnly": false - }, - "dramaSubAppLoadingShellTransparent": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaSubAppLoadingShellTransparent": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeleton": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeleton": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonMain": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonMain": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonHero": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonHero": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonTabPanel": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonTabPanel": 3 - }, - "teamOnly": false - }, - "dhsRedrawPanel": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dhsRedrawPanel": 3 - }, - "teamOnly": false - }, - "dhsRedrawHero": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dhsRedrawHero": 3 - }, - "teamOnly": false - }, - "dhsRedrawTitle": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dhsRedrawTitle": 3 - }, - "teamOnly": false - }, - "dhsRedrawEmpty": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dhsRedrawEmpty": 3 - }, - "teamOnly": false - }, - "dhsRedrawEmptyInner": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dhsRedrawEmptyInner": 3 - }, - "teamOnly": false - }, - "dhsRedrawMain": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dhsRedrawMain": 3 - }, - "teamOnly": false - }, - "dhsRedrawCards": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dhsRedrawCards": 3 - }, - "teamOnly": false - }, - "dhsRedrawCopy": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dhsRedrawCopy": 3 - }, - "teamOnly": false - }, - "dhsRedrawEmptyTitle": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dhsRedrawEmptyTitle": 3 - }, - "teamOnly": false - }, - "dhsRedrawEmptyDesc": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dhsRedrawEmptyDesc": 3 - }, - "teamOnly": false - }, - "dhsRedrawActions": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dhsRedrawActions": 3 - }, - "teamOnly": false - }, - "dhsRedrawPillFolder": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dhsRedrawPillFolder": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonDraftWrap": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonDraftWrap": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjects": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonProjects": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectsInner": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonProjectsInner": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectHeader": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonProjectHeader": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectTitle": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonProjectTitle": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectAllBtn": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonProjectAllBtn": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectViewport": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonProjectViewport": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonProjectStrip": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonProjectStrip": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonViral": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonViral": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonViralHeader": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonViralHeader": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonViralTitle": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonViralTitle": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonViralTabs": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonViralTabs": 3 - }, - "teamOnly": false - }, - "dramaHomeSkeletonViralGrid": { - "totalUsage": 3, - "pageCount": 3, - "pages": { - "drama": 1, - "shortvideo": 1, - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonViralGrid": 3 - }, - "teamOnly": false - }, - "asset-category-filter": { - "totalUsage": 68, - "pageCount": 2, - "pages": { - "home": 36, - "asset": 32 - }, - "members": { - "asset-category-filter__pill": 13, - "asset-category-filter__pill-label": 13, - "asset-category-filter__pill-ghost": 13, - "asset-category-filter__pill-text": 13, - "asset-category-filter__pill--inactive": 11, - "asset-category-filter": 2, - "asset-category-filter__pill--active": 2, - "asset-category-filter--sm": 1 - }, - "teamOnly": false - }, - "dhsDramaCard": { - "totalUsage": 6, - "pageCount": 2, - "pages": { - "drama": 3, - "shortvideo": 3 - }, - "members": { - "dhsDramaCard": 6 - }, - "teamOnly": false - }, - "is-selected": { - "totalUsage": 6, - "pageCount": 2, - "pages": { - "shortvideo": 1, - "script": 5 - }, - "members": { - "is-selected": 6 - }, - "teamOnly": false - }, - "-translate-y-1/2": { - "totalUsage": 3, - "pageCount": 2, - "pages": { - "shortvideo": 1, - "script": 2 - }, - "members": { - "-translate-y-1/2": 3 - }, - "teamOnly": false - }, - "asset-category-filter-host": { - "totalUsage": 2, - "pageCount": 2, - "pages": { - "home": 1, - "asset": 1 - }, - "members": { - "asset-category-filter-host": 2 - }, - "teamOnly": false - }, - "dhsDramaCardLeft": { - "totalUsage": 2, - "pageCount": 2, - "pages": { - "drama": 1, - "shortvideo": 1 - }, - "members": { - "dhsDramaCardLeft": 2 - }, - "teamOnly": false - }, - "dhsDramaCardRight": { - "totalUsage": 2, - "pageCount": 2, - "pages": { - "drama": 1, - "shortvideo": 1 - }, - "members": { - "dhsDramaCardRight": 2 - }, - "teamOnly": false - }, - "dhsDramaCardCenter": { - "totalUsage": 2, - "pageCount": 2, - "pages": { - "drama": 1, - "shortvideo": 1 - }, - "members": { - "dhsDramaCardCenter": 2 - }, - "teamOnly": false - }, - "asset-multi-select-filter": { - "totalUsage": 266, - "pageCount": 1, - "pages": { - "asset": 266 - }, - "members": { - "asset-multi-select-filter__option-label": 121, - "asset-multi-select-filter__check": 121, - "asset-multi-select-filter": 4, - "asset-multi-select-filter__text": 4, - "asset-multi-select-filter__chevron": 4, - "asset-multi-select-filter__popper": 4, - "asset-multi-select-filter__panel": 4, - "asset-multi-select-filter__search": 2, - "asset-multi-select-filter__search-input": 2 - }, - "teamOnly": false - }, - "featured-card": { - "totalUsage": 260, - "pageCount": 1, - "pages": { - "home": 260 - }, - "members": { - "featured-card": 20, - "featured-card--landscape": 20, - "featured-card__media": 20, - "featured-card__badge": 20, - "featured-card__like": 20, - "featured-card__like-icon-wrap": 20, - "featured-card__like-icon": 20, - "featured-card__like-count": 20, - "featured-card__meta": 20, - "featured-card__creator": 20, - "featured-card__creator-avatar": 20, - "featured-card__creator-name": 20, - "featured-card__labels": 20 - }, - "teamOnly": false - }, - "asset-card": { - "totalUsage": 180, - "pageCount": 1, - "pages": { - "asset": 180 - }, - "members": { - "asset-card": 20, - "asset-card--clickable": 20, - "asset-card--meta": 20, - "asset-card__cover": 20, - "asset-card__meta-tags": 20, - "asset-card__meta-corner": 20, - "asset-card__icon-btn": 20, - "asset-card__icon-img": 20, - "asset-card__icon-img--favorite": 20 - }, - "teamOnly": false - }, - "asset-card-official-meta": { - "totalUsage": 160, - "pageCount": 1, - "pages": { - "asset": 160 - }, - "members": { - "asset-card-official-meta": 20, - "asset-card-official-meta__body": 20, - "asset-card-official-meta__title": 20, - "asset-card-official-meta__creator": 20, - "asset-card-official-meta__creator-name": 20, - "asset-card-official-meta__add": 20, - "asset-card-official-meta__add-btn": 20, - "asset-card-official-meta__action-icon": 20 - }, - "teamOnly": false - }, - "asset-media-cover": { - "totalUsage": 80, - "pageCount": 1, - "pages": { - "asset": 80 - }, - "members": { - "asset-media-cover": 20, - "asset-media-cover--ratio": 20, - "asset-media-cover__media": 20, - "asset-media-cover__media--cover": 20 - }, - "teamOnly": false - }, - "asset-default-avatar": { - "totalUsage": 60, - "pageCount": 1, - "pages": { - "asset": 60 - }, - "members": { - "asset-default-avatar": 20, - "asset-default-avatar--official-placeholder": 20, - "asset-default-avatar__official-icon": 20 - }, - "teamOnly": false - }, - "creative-skill-card": { - "totalUsage": 54, - "pageCount": 1, - "pages": { - "shortvideo": 54 - }, - "members": { - "creative-skill-card": 9, - "creative-skill-card__cover": 9, - "creative-skill-card__body": 9, - "creative-skill-card__title": 9, - "creative-skill-card__desc": 9, - "creative-skill-card__meta": 9 - }, - "teamOnly": false - }, - "quick-card": { - "totalUsage": 40, - "pageCount": 1, - "pages": { - "home": 40 - }, - "members": { - "quick-card": 4, - "quick-card__text": 4, - "quick-card__title": 4, - "quick-card__desc": 4, - "quick-card__visual": 4, - "quick-card__image": 4, - "quick-card__border": 4, - "quick-card__spotlight": 4, - "quick-card__beam": 4, - "quick-card__arrow": 3, - "quick-card--split": 1 - }, - "teamOnly": false - }, - "asset-main-tabs": { - "totalUsage": 24, - "pageCount": 1, - "pages": { - "asset": 24 - }, - "members": { - "asset-main-tabs__item": 4, - "asset-main-tabs__label": 4, - "asset-main-tabs__icon": 3, - "asset-main-tabs__icon-img": 3, - "asset-main-tabs__item--inactive": 3, - "asset-main-tabs__badge": 2, - "asset-main-tabs": 1, - "asset-main-tabs__item--active": 1, - "asset-main-tabs__badge--inactive": 1, - "asset-main-tabs__item--disabled": 1, - "asset-main-tabs__badge--coming-soon": 1 - }, - "teamOnly": false - }, - "asset-track-filter": { - "totalUsage": 23, - "pageCount": 1, - "pages": { - "home": 23 - }, - "members": { - "asset-track-filter__tab": 7, - "asset-track-filter__label": 7, - "asset-track-filter__tab--inactive": 6, - "asset-track-filter": 1, - "asset-track-filter__tab--active": 1, - "asset-track-filter__tab--disabled": 1 - }, - "teamOnly": false - }, - "waterfall": { - "totalUsage": 21, - "pageCount": 1, - "pages": { - "asset": 21 - }, - "members": { - "waterfall__item": 20, - "waterfall__grid": 1 - }, - "teamOnly": false - }, - "home-hero-carousel": { - "totalUsage": 20, - "pageCount": 1, - "pages": { - "home": 20 - }, - "members": { - "home-hero-carousel__card": 3, - "home-hero-carousel__card-inner": 3, - "home-hero-carousel__overlay": 3, - "home-hero-carousel__dot": 3, - "home-hero-carousel__nav": 2, - "home-hero-carousel__nav-icon": 2, - "home-hero-carousel__stage": 1, - "home-hero-carousel__nav--prev": 1, - "home-hero-carousel__nav--next": 1, - "home-hero-carousel__dots": 1 - }, - "teamOnly": false - }, - "featured-card-wrap": { - "totalUsage": 20, - "pageCount": 1, - "pages": { - "home": 20 - }, - "members": { - "featured-card-wrap": 20 - }, - "teamOnly": false - }, - "asset-tag": { - "totalUsage": 20, - "pageCount": 1, - "pages": { - "asset": 20 - }, - "members": { - "asset-tag": 20 - }, - "teamOnly": false - }, - "quick-split": { - "totalUsage": 19, - "pageCount": 1, - "pages": { - "home": 19 - }, - "members": { - "quick-split__item": 2, - "quick-split__panel": 2, - "quick-split__icon": 2, - "quick-split__text": 2, - "quick-split__heading": 2, - "quick-split__title": 2, - "quick-split__arrow": 2, - "quick-split__desc": 2, - "quick-split": 1, - "quick-split__item--left": 1, - "quick-split__item--right": 1 - }, - "teamOnly": false - }, - "index-feature-card": { - "totalUsage": 18, - "pageCount": 1, - "pages": { - "script": 18 - }, - "members": { - "index-feature-card": 4, - "index-feature-card__icon": 4, - "index-feature-card__action": 4, - "index-feature-card__hover-icon": 4, - "index-feature-card--wide": 1, - "index-feature-card__deco": 1 - }, - "teamOnly": false - }, - "app-footer": { - "totalUsage": 14, - "pageCount": 1, - "pages": { - "home": 14 - }, - "members": { - "app-footer__link": 6, - "app-footer__sep": 4, - "app-footer": 1, - "app-footer__icp": 1, - "app-footer__company": 1, - "app-footer__meta-item": 1 - }, - "teamOnly": false - }, - "asset-track-pill-bar": { - "totalUsage": 14, - "pageCount": 1, - "pages": { - "asset": 14 - }, - "members": { - "asset-track-pill-bar__pill": 6, - "asset-track-pill-bar__pill--inactive": 5, - "asset-track-pill-bar": 1, - "asset-track-pill-bar__tracks": 1, - "asset-track-pill-bar__pill--active": 1 - }, - "teamOnly": false - }, - "agent-run-mode-item": { - "totalUsage": 11, - "pageCount": 1, - "pages": { - "shortvideo": 11 - }, - "members": { - "agent-run-mode-item": 2, - "agent-run-mode-item__icon": 2, - "agent-run-mode-item__text": 2, - "agent-run-mode-item__label": 2, - "agent-run-mode-item__desc": 2, - "agent-run-mode-item__check": 1 - }, - "teamOnly": false - }, - "asset-search-field": { - "totalUsage": 11, - "pageCount": 1, - "pages": { - "asset": 11 - }, - "members": { - "asset-search-field": 1, - "asset-search-field--with-btn": 1, - "asset-search-field--official": 1, - "asset-search-field__input": 1, - "asset-search-field__divider": 1, - "asset-search-field__img-slot": 1, - "asset-search-field__img-btn": 1, - "asset-search-field__img-btn--idle": 1, - "asset-search-field__btn": 1, - "asset-search-field__btn--ai": 1, - "asset-search-field__btn-ai-icon": 1 - }, - "teamOnly": false - }, - "creative-start-card": { - "totalUsage": 9, - "pageCount": 1, - "pages": { - "shortvideo": 9 - }, - "members": { - "creative-start-card__ghost-line": 2, - "creative-start-card": 1, - "creative-start-card__ghost": 1, - "creative-start-card__ghost-cover": 1, - "creative-start-card__ghost-info": 1, - "creative-start-card__ghost-line--sm": 1, - "creative-start-card__content": 1, - "creative-start-card__icon": 1 - }, - "teamOnly": false - }, - "cutm-item": { - "totalUsage": 9, - "pageCount": 1, - "pages": { - "shortvideo": 9 - }, - "members": { - "cutm-item": 3, - "cutm-item__label": 3, - "cutm-item__icon": 2, - "cutm-item__img": 1 - }, - "teamOnly": false - }, - "project-folder-design-v2": { - "totalUsage": 9, - "pageCount": 1, - "pages": { - "space": 9 - }, - "members": { - "project-folder-design-v2__sparkle": 2, - "project-folder-design-v2__stage": 1, - "project-folder-design-v2__back-assembly": 1, - "project-folder-design-v2__back": 1, - "project-folder-design-v2__front-assembly": 1, - "project-folder-design-v2__sparkles": 1, - "project-folder-design-v2__sparkle--lg": 1, - "project-folder-design-v2__sparkle--sm": 1 - }, - "teamOnly": false - }, - "script-square-filter-popper": { - "totalUsage": 8, - "pageCount": 1, - "pages": { - "script": 8 - }, - "members": { - "script-square-filter-popper": 5, - "script-square-filter-popper--multi": 3 - }, - "teamOnly": false - }, - "space-last-viewed-hint": { - "totalUsage": 8, - "pageCount": 1, - "pages": { - "space": 8 - }, - "members": { - "space-last-viewed-hint--card": 1, - "space-last-viewed-hint--rim": 1, - "space-last-viewed-hint__glow": 1, - "space-last-viewed-hint__rim": 1, - "space-last-viewed-hint__rim-spin": 1, - "space-last-viewed-hint--cover": 1, - "space-last-viewed-hint__veil": 1, - "space-last-viewed-hint__label": 1 - }, - "teamOnly": false - }, - "space-create-button": { - "totalUsage": 5, - "pageCount": 1, - "pages": { - "space": 5 - }, - "members": { - "space-create-button__icon": 4, - "space-create-button__icon--lg": 1 - }, - "teamOnly": false - }, - "is-plain": { - "totalUsage": 5, - "pageCount": 1, - "pages": { - "space": 5 - }, - "members": { - "is-plain": 5 - }, - "teamOnly": false - }, - "home-carousel-card-media": { - "totalUsage": 4, - "pageCount": 1, - "pages": { - "home": 4 - }, - "members": { - "home-carousel-card-media__layer": 4 - }, - "teamOnly": false - }, - "feature-entry-hover-content": { - "totalUsage": 4, - "pageCount": 1, - "pages": { - "script": 4 - }, - "members": { - "feature-entry-hover-content": 4 - }, - "teamOnly": false - }, - "space-quota-progress": { - "totalUsage": 4, - "pageCount": 1, - "pages": { - "space": 4 - }, - "members": { - "space-quota-progress--team-home": 1, - "space-quota-progress__divider": 1, - "space-quota-progress__badge": 1, - "space-quota-progress__track": 1 - }, - "teamOnly": false - }, - "onboarding-divider": { - "totalUsage": 4, - "pageCount": 1, - "pages": { - "team": 4 - }, - "members": { - "onboarding-divider__line": 2, - "onboarding-divider__line--left": 1, - "onboarding-divider__line--right": 1 - }, - "teamOnly": true - }, - "cib": { - "totalUsage": 3, - "pageCount": 1, - "pages": { - "shortvideo": 3 - }, - "members": { - "cib": 1, - "cib--home": 1, - "cib--expanded": 1 - }, - "teamOnly": false - }, - "css-tab": { - "totalUsage": 3, - "pageCount": 1, - "pages": { - "shortvideo": 3 - }, - "members": { - "css-tab": 3 - }, - "teamOnly": false - }, - "asset-copyright-tip": { - "totalUsage": 3, - "pageCount": 1, - "pages": { - "asset": 3 - }, - "members": { - "asset-copyright-tip": 1, - "asset-copyright-tip__trigger": 1, - "asset-copyright-tip__icon": 1 - }, - "teamOnly": false - }, - "official-asset-banner": { - "totalUsage": 3, - "pageCount": 1, - "pages": { - "asset": 3 - }, - "members": { - "official-asset-banner": 1, - "official-asset-banner__title": 1, - "official-asset-banner__desc": 1 - }, - "teamOnly": false - }, - "is-circle": { - "totalUsage": 3, - "pageCount": 1, - "pages": { - "space": 3 - }, - "members": { - "is-circle": 3 - }, - "teamOnly": false - }, - "onboarding-feature": { - "totalUsage": 3, - "pageCount": 1, - "pages": { - "team": 3 - }, - "members": { - "onboarding-feature__title": 3 - }, - "teamOnly": true - }, - "is-side": { - "totalUsage": 2, - "pageCount": 1, - "pages": { - "home": 2 - }, - "members": { - "is-side": 2 - }, - "teamOnly": false - }, - "featured-artist-tab": { - "totalUsage": 2, - "pageCount": 1, - "pages": { - "home": 2 - }, - "members": { - "featured-artist-tab": 1, - "featured-artist-tab__badge": 1 - }, - "teamOnly": false - }, - "asset-recommend-subfilters": { - "totalUsage": 2, - "pageCount": 1, - "pages": { - "home": 2 - }, - "members": { - "asset-recommend-subfilters": 1, - "asset-recommend-subfilters__tools": 1 - }, - "teamOnly": false - }, - "featured-asset-player-overlay": { - "totalUsage": 2, - "pageCount": 1, - "pages": { - "home": 2 - }, - "members": { - "featured-asset-player-overlay": 2 - }, - "teamOnly": false - }, - "cars-trigger": { - "totalUsage": 2, - "pageCount": 1, - "pages": { - "shortvideo": 2 - }, - "members": { - "cars-trigger": 1, - "cars-trigger--pill": 1 - }, - "teamOnly": false - }, - "section-header": { - "totalUsage": 2, - "pageCount": 1, - "pages": { - "shortvideo": 2 - }, - "members": { - "section-header__view-all": 2 - }, - "teamOnly": false - }, - "index-hit-hero": { - "totalUsage": 2, - "pageCount": 1, - "pages": { - "script": 2 - }, - "members": { - "index-hit-hero": 1, - "index-hit-hero__inner": 1 - }, - "teamOnly": false - }, - "asset-page": { - "totalUsage": 2, - "pageCount": 1, - "pages": { - "asset": 2 - }, - "members": { - "asset-page": 1, - "asset-page__header": 1 - }, - "teamOnly": false - }, - "asset-field-input": { - "totalUsage": 2, - "pageCount": 1, - "pages": { - "asset": 2 - }, - "members": { - "asset-field-input": 1, - "asset-field-input--plain": 1 - }, - "teamOnly": false - }, - "space-view-icon": { - "totalUsage": 2, - "pageCount": 1, - "pages": { - "space": 2 - }, - "members": { - "space-view-icon--grid": 1, - "space-view-icon--list": 1 - }, - "teamOnly": false - }, - "app-aurora": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "app-aurora": 1 - }, - "teamOnly": false - }, - "router-link-exact-active": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "router-link-exact-active": 1 - }, - "teamOnly": false - }, - "is-center": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "is-center": 1 - }, - "teamOnly": false - }, - "-rotate-90": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "-rotate-90": 1 - }, - "teamOnly": false - }, - "banner-container": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "banner-container": 1 - }, - "teamOnly": false - }, - "banner-title": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "banner-title": 1 - }, - "teamOnly": false - }, - "banner-subtitle": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "banner-subtitle": 1 - }, - "teamOnly": false - }, - "asset-recommend-section": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "asset-recommend-section": 1 - }, - "teamOnly": false - }, - "asset-recommend-filters": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "asset-recommend-filters": 1 - }, - "teamOnly": false - }, - "asset-recommend-list": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "asset-recommend-list": 1 - }, - "teamOnly": false - }, - "featured-asset-grid": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "featured-asset-grid": 1 - }, - "teamOnly": false - }, - "create-mode-modal": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "create-mode-modal": 1 - }, - "teamOnly": false - }, - "jump-tv-detail-overlay": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "jump-tv-detail-overlay": 1 - }, - "teamOnly": false - }, - "official-asset-mobile-preview-overlay": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "home": 1 - }, - "members": { - "official-asset-mobile-preview-overlay": 1 - }, - "teamOnly": false - }, - "creativeHomeComposer": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "creativeHomeComposer": 1 - }, - "teamOnly": false - }, - "creativeHomeHeroTitle": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "creativeHomeHeroTitle": 1 - }, - "teamOnly": false - }, - "cmi": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "cmi": 1 - }, - "teamOnly": false - }, - "is-focused": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "is-focused": 1 - }, - "teamOnly": false - }, - "cib-textarea": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "cib-textarea": 1 - }, - "teamOnly": false - }, - "cmi-content": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "cmi-content": 1 - }, - "teamOnly": false - }, - "tiptap": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "tiptap": 1 - }, - "teamOnly": false - }, - "ProseMirror": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "ProseMirror": 1 - }, - "teamOnly": false - }, - "ProseMirror-focused": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "ProseMirror-focused": 1 - }, - "teamOnly": false - }, - "is-empty": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "is-empty": 1 - }, - "teamOnly": false - }, - "is-editor-empty": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "is-editor-empty": 1 - }, - "teamOnly": false - }, - "ProseMirror-trailingBreak": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "ProseMirror-trailingBreak": 1 - }, - "teamOnly": false - }, - "cib-toolbar": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "cib-toolbar": 1 - }, - "teamOnly": false - }, - "cib-tools-left": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "cib-tools-left": 1 - }, - "teamOnly": false - }, - "cutm-trigger": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "cutm-trigger": 1 - }, - "teamOnly": false - }, - "css-trigger": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "css-trigger": 1 - }, - "teamOnly": false - }, - "cib-tools-right": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "cib-tools-right": 1 - }, - "teamOnly": false - }, - "cib-mode": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "cib-mode": 1 - }, - "teamOnly": false - }, - "cib-send": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "cib-send": 1 - }, - "teamOnly": false - }, - "examples-scroller": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "examples-scroller": 1 - }, - "teamOnly": false - }, - "creationWorkbenchDramaSlotParked": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "creationWorkbenchDramaSlotParked": 1 - }, - "teamOnly": false - }, - "creative-upload-type-dropdown": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "creative-upload-type-dropdown": 1 - }, - "teamOnly": false - }, - "creative-upload-type-menu": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "creative-upload-type-menu": 1 - }, - "teamOnly": false - }, - "creative-skill-popover": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "creative-skill-popover": 1 - }, - "teamOnly": false - }, - "css-pill": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "css-pill": 1 - }, - "teamOnly": false - }, - "css-search-input": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "css-search-input": 1 - }, - "teamOnly": false - }, - "css-list": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "css-list": 1 - }, - "teamOnly": false - }, - "creative-mode-dropdown": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "creative-mode-dropdown": 1 - }, - "teamOnly": false - }, - "creative-mode-menu": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "creative-mode-menu": 1 - }, - "teamOnly": false - }, - "creative-agent-run-mode-popover": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "creative-agent-run-mode-popover": 1 - }, - "teamOnly": false - }, - "agent-run-mode-panel": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "agent-run-mode-panel": 1 - }, - "teamOnly": false - }, - "asset-picker-dialog-overlay": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "shortvideo": 1 - }, - "members": { - "asset-picker-dialog-overlay": 1 - }, - "teamOnly": false - }, - "dramaHomeSkeletonRedraw": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "redraw": 1 - }, - "members": { - "dramaHomeSkeletonRedraw": 1 - }, - "teamOnly": false - }, - "dhsRedrawCardLeft": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "redraw": 1 - }, - "members": { - "dhsRedrawCardLeft": 1 - }, - "teamOnly": false - }, - "dhsRedrawCardRight": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "redraw": 1 - }, - "members": { - "dhsRedrawCardRight": 1 - }, - "teamOnly": false - }, - "dhsRedrawCardCenter": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "redraw": 1 - }, - "members": { - "dhsRedrawCardCenter": 1 - }, - "teamOnly": false - }, - "index-hit-hero-glow": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "script": 1 - }, - "members": { - "index-hit-hero-glow": 1 - }, - "teamOnly": false - }, - "script-list-card-more": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "script": 1 - }, - "members": { - "script-list-card-more": 1 - }, - "teamOnly": false - }, - "-translate-x-1/2": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "script": 1 - }, - "members": { - "-translate-x-1/2": 1 - }, - "teamOnly": false - }, - "script-square-section": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "script": 1 - }, - "members": { - "script-square-section": 1 - }, - "teamOnly": false - }, - "script-square-tabs": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "script": 1 - }, - "members": { - "script-square-tabs": 1 - }, - "teamOnly": false - }, - "script-square-card-scroll": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "script": 1 - }, - "members": { - "script-square-card-scroll": 1 - }, - "teamOnly": false - }, - "script-list-card-dropdown": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "script": 1 - }, - "members": { - "script-list-card-dropdown": 1 - }, - "teamOnly": false - }, - "script-list-menu-item": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "script": 1 - }, - "members": { - "script-list-menu-item--danger": 1 - }, - "teamOnly": false - }, - "script-square-purchase-modal": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "script": 1 - }, - "members": { - "script-square-purchase-modal": 1 - }, - "teamOnly": false - }, - "script-square-detail-modal": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "script": 1 - }, - "members": { - "script-square-detail-modal": 1 - }, - "teamOnly": false - }, - "script-feature-gate-modal": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "script": 1 - }, - "members": { - "script-feature-gate-modal": 1 - }, - "teamOnly": false - }, - "asset-official-panel": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "asset": 1 - }, - "members": { - "asset-official-panel": 1 - }, - "teamOnly": false - }, - "asset-waterfall-scroll": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "asset": 1 - }, - "members": { - "asset-waterfall-scroll": 1 - }, - "teamOnly": false - }, - "asset-official-filters": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "asset": 1 - }, - "members": { - "asset-official-filters": 1 - }, - "teamOnly": false - }, - "asset-official-filter-row": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "asset": 1 - }, - "members": { - "asset-official-filter-row": 1 - }, - "teamOnly": false - }, - "asset-waterfall": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "asset": 1 - }, - "members": { - "asset-waterfall": 1 - }, - "teamOnly": false - }, - "space-layout": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "space": 1 - }, - "members": { - "space-layout__project-header": 1 - }, - "teamOnly": false - }, - "space-page-header": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "space": 1 - }, - "members": { - "space-page-header__quota-actions": 1 - }, - "teamOnly": false - }, - "is-round": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "space": 1 - }, - "members": { - "is-round": 1 - }, - "teamOnly": false - }, - "space-team-search-button": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "space": 1 - }, - "members": { - "space-team-search-button__icon": 1 - }, - "teamOnly": false - }, - "space-view-switch": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "space": 1 - }, - "members": { - "space-view-switch--team-home": 1 - }, - "teamOnly": false - }, - "space-more-menu": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "space": 1 - }, - "members": { - "space-more-menu--card-overlay": 1 - }, - "teamOnly": false - }, - "space-more-button": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "space": 1 - }, - "members": { - "space-more-button--card-overlay": 1 - }, - "teamOnly": false - }, - "space-more-dropdown": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "space": 1 - }, - "members": { - "space-more-dropdown--card": 1 - }, - "teamOnly": false - }, - "team-scope-content": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "team": 1 - }, - "members": { - "team-scope-content": 1 - }, - "teamOnly": true - }, - "team-onboarding-card": { - "totalUsage": 1, - "pageCount": 1, - "pages": { - "team": 1 - }, - "members": { - "team-onboarding-card": 1 - }, - "teamOnly": true - } - }, - "elementPlus": { - "el-tooltip__trigger": 358, - "el-dropdown-menu__item": 294, - "el-overlay": 218, - "el-modal-dialog": 209, - "el-overlay-dialog": 209, - "el-icon": 102, - "el-popper": 69, - "el-tooltip": 69, - "el-popover": 56, - "el-input": 56, - "el-input__wrapper": 56, - "el-input__inner": 56, - "el-input--large": 54, - "el-scrollbar__bar": 26, - "el-scrollbar__thumb": 26, - "el-input--suffix": 20, - "el-input__suffix": 20, - "el-input__suffix-inner": 20, - "el-dialog": 18, - "el-dialog__header": 18, - "el-dialog__title": 18, - "el-dialog__body": 18, - "el-dropdown": 13, - "el-dropdown__popper": 13, - "el-scrollbar": 13, - "el-scrollbar__wrap": 13, - "el-scrollbar__wrap--hidden-default": 13, - "el-scrollbar__view": 13, - "el-dropdown__list": 13, - "el-dropdown-menu": 13, - "el-popper__arrow": 11, - "el-badge": 9, - "el-badge__content": 9, - "el-badge__content--danger": 9, - "el-form": 9, - "el-form--default": 9, - "el-form--label-right": 9, - "el-checkbox": 9, - "el-checkbox--large": 9, - "el-checkbox__input": 9, - "el-checkbox__original": 9, - "el-checkbox__inner": 9, - "el-modal-drawer": 9, - "el-drawer": 9, - "el-drawer__sr-focus": 9, - "el-button": 6, - "el-button--primary": 6, - "el-input__icon": 3, - "el-input__clear": 2, - "el-input--prefix": 1, - "el-input__prefix": 1, - "el-input__prefix-inner": 1 - } -} \ No newline at end of file diff --git a/product-planning/references/stage-delivery/references/execution-runbook.md b/product-planning/references/stage-delivery/references/execution-runbook.md index 292989f..63d61e0 100644 --- a/product-planning/references/stage-delivery/references/execution-runbook.md +++ b/product-planning/references/stage-delivery/references/execution-runbook.md @@ -53,7 +53,7 @@ | D4 | `craft/animation-discipline.md` | 动效三问、弹簧二参数（取代原 `04_动效与手势规则.md`） | | D5 | `design-templates/web-prototype/references/checklist.md` + `craft/anti-ai-slop.md` + `craft/accessibility-baseline.md` | 终检清单、反 AI 味、无障碍底线（取代原 `05_审计门禁与输出格式.md`）。⚠️ 工具型页面必须过 checklist 的 `P0-A 标题区纪律`（2026-10-05 新增，五条） | | D5 独立评审（按需） | `oil-ui-pro` 的 `references/visual-review.md` + `references/tools.md` | 要「没看过制作过程的评审打分」时的协议与截图取证（不替代本段 Gate） | -| 每步 | `docs/pm/<项目>/DESIGN.md` | 本项目绑定规范；原型只许引它的 token | +| 每步 | `产品原型/designs/DESIGN.md` | 本项目绑定规范；原型只许引它的 token | ⛔ 四样东西 craft 没有对应，必须留在本项目（本文件 / `SKILL.md` / `references/layouts-tooling.md` 里）： @@ -174,7 +174,7 @@ > 组件规格是「草稿感」的分水岭。同一屏里按钮高度不一、内衬不一、字号不一，观感立刻散。分档靠填充色 ＋ 高度，不靠字号；同一父区块内主档 ≤1 个（多步流程每步 ≤1 个）；实底按钮底色至少 2 种（全是同一个实底色，等于没有分档）；卡片内衬只许两档（密卡 / 宽松卡），同层级卡片圆角与内衬必须同值。 -### 2.3 落盘 `docs/pm/<项目>/DESIGN.md` +### 2.3 落盘 `产品原型/designs/DESIGN.md` 令牌表内容并入本项目既有的三层 token 结构：`primitive → semantic → component`。组件层只引语义层，语义层只引 primitive，无孤立 token。设计契约作首节。 @@ -220,23 +220,23 @@ - `web-prototype` 的默认产出是单文件 HTML、自包含、双击可开。这也是交付形态，最终必须满足 - 本项目的原型用 React + Babel 多文件开发（`index.html` ＋ 若干 `.jsx`），经 HTTP 服务预览（`file://` 下 Babel 取不到外部 `.jsx`，会静默失败） - 编排：开发期按多文件走 ＋ HTTP 预览，3b 收尾时内联成单文件交付 -- 无宿主工具可代劳，内联必须手工做：把 React / ReactDOM / Babel 用本仓本地副本内联（保离线），把每个 `" not in src: + # 开标签按正则认：③段原型常写 `" not in src: return C.die("原型里没有 `") js = src[i:j] fails = [] diff --git a/product-planning/references/stage-delivery/scripts/check_skeleton.py b/product-planning/references/stage-delivery/scripts/check_skeleton.py index da52b2d..50aa9fb 100644 --- a/product-planning/references/stage-delivery/scripts/check_skeleton.py +++ b/product-planning/references/stage-delivery/scripts/check_skeleton.py @@ -13,9 +13,9 @@ 「按旧页数静默比错」；这类副本一旦散在各项目里，同一条闸门会出现多个版本。 用法： - python check_skeleton.py --ws <工作区> # 自动找 ②段 与 原型 + python check_skeleton.py --ws <工作区或产品根> # 自动找 ②段 与 原型 python check_skeleton.py --doc X.md --proto Y.html # 指定两份 - python check_skeleton.py --ws <工作区> --expect-pages 7 # 想额外钉住页数时才给 + python check_skeleton.py --ws <工作区或产品根> --expect-pages 7 # 想额外钉住页数时才给 退出码：0 = PASS；1 = FAIL（列出每一处不一致）；2 = 用法／定位失败。 """ import argparse @@ -96,16 +96,16 @@ def norm(x): def main(): ap = argparse.ArgumentParser(description="③段闸门①：②段骨架 ↔ 原型 FROZEN 表") - ap.add_argument("--ws", default="", help="工作区根（缺省＝当前目录）") - ap.add_argument("--doc", default="", help="②段界面布局（缺省＝自动找 docs/pm/*/prd/2b-*.md）") - ap.add_argument("--proto", default="", help="原型 HTML（缺省＝自动找 docs/pm/*/ui/*.html）") + ap.add_argument("--ws", default="", help="工作区根或产品根（缺省＝当前目录，会向上认到产品根）") + ap.add_argument("--doc", default="", help="②段界面布局（缺省＝在产品根下自动找 产品规划/prd/2b-*.md）") + ap.add_argument("--proto", default="", help="原型 HTML（缺省＝在产品根下自动找 产品原型/pages/*.html）") ap.add_argument("--expect-pages", type=int, default=0, help="想额外钉住页数时才给") a = ap.parse_args() ws, doc, proto = C.resolve(a.ws, a.doc, a.proto) if not doc: - return C.die("没找到 ②段界面布局（找过 %s/docs/pm/*/prd/2b-*.md）" % ws) + return C.die("没找到 ②段界面布局（找过 %s/产品规划/prd/2b-*.md）" % ws) if not proto: - return C.die("没找到原型 HTML（找过 %s/docs/pm/*/ui/*.html）" % ws) + return C.die("没找到原型 HTML（找过 %s/产品原型/pages/*.html）" % ws) d, p = from_doc(doc), from_proto(proto) bad = [] diff --git a/product-planning/references/stage-delivery/scripts/selftest_gates.py b/product-planning/references/stage-delivery/scripts/selftest_gates.py index b88f46c..34a12e9 100644 --- a/product-planning/references/stage-delivery/scripts/selftest_gates.py +++ b/product-planning/references/stage-delivery/scripts/selftest_gates.py @@ -48,15 +48,15 @@ def _brief(out, n=2): def main(): ap = argparse.ArgumentParser(description="③段闸门自身的变异对照") - ap.add_argument("--ws", default="", help="工作区根（缺省＝当前目录）") + ap.add_argument("--ws", default="", help="工作区根或产品根（缺省＝当前目录，会向上认到产品根）") ap.add_argument("--doc", default="", help="②段界面布局（缺省＝自动找）") ap.add_argument("--proto", default="", help="原型 HTML（缺省＝自动找）") a = ap.parse_args() ws, doc, proto = C.resolve(a.ws, a.doc, a.proto) if not doc: - return C.die("没找到 ②段界面布局（找过 %s/docs/pm/*/prd/2b-*.md）" % ws) + return C.die("没找到 ②段界面布局（找过 %s/产品规划/prd/2b-*.md）" % ws) if not proto: - return C.die("没找到原型 HTML（找过 %s/docs/pm/*/ui/*.html）" % ws) + return C.die("没找到原型 HTML（找过 %s/产品原型/pages/*.html）" % ws) tmp = tempfile.mkdtemp(prefix="gate-selftest-") rows = [] try: @@ -95,7 +95,10 @@ def main(): print(" 骨架 rc=%d（期望 1）｜ %s" % (c3, _brief(o3, 2))) # 变异 2：script 区里塞一个含反引号的 HTML 注释 - k = h.index("