@sushanglewis/lincoln 1.5.4 → 1.6.1

package/framework/.claude/hooks/pre-tool-use.sh

@@ -175,7 +175,7 @@ if [[ -n "$TARGET_PATH" ]]; then
         exit 1
     fi
 
-    if [[ "$NORMALIZED_TARGET" == "$PROCESS_SLUG/prd-v"*.md ]] && is_side_effect "$TOOL_NAME"; then
+    if [[ "$NORMALIZED_TARGET" == "$PROCESS_SLUG/prd-v"*.md || "$NORMALIZED_TARGET" == "$PROCESS_SLUG/pages/docs/snapshots/prd-v"*.html ]] && is_side_effect "$TOOL_NAME"; then
         echo "BLOCKED: PRD snapshots are immutable. Create them with 'python scripts/lincoln_prd.py freeze'." >&2
         exit 1
     fi
@@ -193,7 +193,7 @@ if [[ -n "$TARGET_PATH" ]]; then
     if is_side_effect "$TOOL_NAME"; then
         if [[ -n "$PROCESS_SLUG" ]]; then
             case "$NORMALIZED_TARGET" in
-                recordings/*|*/recordings/*|interviews/*|*/interviews/*|requirements/*|*/requirements/*|designs/*|*/designs/*|openspec/changes/*|*/openspec/changes/*|docs/research/*|*/docs/research/*)
+                recordings/*|*/recordings/*|interviews/*|*/interviews/*|requirements/*|*/requirements/*|designs/*|*/designs/*|openspec/changes/*|*/openspec/changes/*|docs/research/*|*/docs/research/*|pages/docs/*|*/pages/docs/*|pages/prototype/*|*/pages/prototype/*|handoffs/*|*/handoffs/*)
                     if [[ "$NORMALIZED_TARGET" != "$PROCESS_SLUG/"* ]]; then
                         echo "BLOCKED: process artifacts must be written under '$PROCESS_SLUG/'." >&2
                         exit 1
@@ -202,7 +202,7 @@ if [[ -n "$TARGET_PATH" ]]; then
             esac
         else
             case "$NORMALIZED_TARGET" in
-                recordings/*|*/recordings/*|interviews/*|*/interviews/*|requirements/*|*/requirements/*|designs/*|*/designs/*|openspec/changes/*|*/openspec/changes/*|docs/research/*|*/docs/research/*)
+                recordings/*|*/recordings/*|interviews/*|*/interviews/*|requirements/*|*/requirements/*|designs/*|*/designs/*|openspec/changes/*|*/openspec/changes/*|docs/research/*|*/docs/research/*|pages/docs/*|*/pages/docs/*|pages/prototype/*|*/pages/prototype/*|handoffs/*|*/handoffs/*)
                     echo "BLOCKED: process artifacts must be written under an initialized <process_slug>/." >&2
                     exit 1
                     ;;

package/framework/.claude/schemas/agent-definition.schema.json

@@ -21,7 +21,12 @@
     },
     "model": {
       "type": "string",
-      "enum": ["haiku", "sonnet", "opus"]
+      "enum": ["haiku", "sonnet", "opus", "fable"]
+    },
+    "language": {
+      "type": "string",
+      "enum": ["zh-CN", "en"],
+      "description": "Primary language of the agent prompt body"
     },
     "tools": {
       "type": "array",

package/framework/.claude/schemas/stage-definition.schema.json

@@ -9,7 +9,7 @@
     "id",
     "name",
     "description",
-    "templates",
+    "workflows",
     "prerequisite_stage",
     "next_stage",
     "human_gate",
@@ -40,7 +40,7 @@
       "minLength": 1,
       "description": "What this stage does and when it is triggered"
     },
-    "templates": {
+    "workflows": {
       "oneOf": [
         {
           "type": "string",
@@ -154,6 +154,47 @@
       },
       "additionalProperties": false
     },
+    "artifact_templates": {
+      "type": "object",
+      "description": "Maps artifact path templates to HTML/template files used to render them",
+      "additionalProperties": {
+        "type": "string",
+        "minLength": 1
+      }
+    },
+    "variables": {
+      "type": "array",
+      "items": {
+        "type": "string",
+        "pattern": "^[a-z][a-z0-9_]*$"
+      },
+      "description": "Variable names used in this stage's path templates and commands"
+    },
+    "execution_mode": {
+      "type": "string",
+      "enum": ["team", "solo", "both"],
+      "default": "both",
+      "description": "Execution mode this stage supports"
+    },
+    "primary_action": {
+      "type": "string",
+      "minLength": 1,
+      "description": "Primary action name that corresponds to the workflow step action"
+    },
+    "references": {
+      "type": "object",
+      "properties": {
+        "skill_prompt": {
+          "type": "string",
+          "minLength": 1
+        },
+        "agent_guide": {
+          "type": "string",
+          "minLength": 1
+        }
+      },
+      "additionalProperties": false
+    },
     "context": {
       "type": "object",
       "required": ["goal"],
@@ -177,7 +218,7 @@
         },
         "constraints": {
           "type": "string",
-          "description": "Additional constraints and guardrails"
+          "description": "Stage-specific constraints and guardrails (generic constraints live in default.md)"
         }
       },
       "additionalProperties": false
@@ -213,12 +254,16 @@
             "artifacts_present",
             "audio_format_supported",
             "previous_stage_completed",
+            "any_of_previous_completed",
             "human_approved",
             "gate_review_passed",
             "handoff_contract_valid",
             "handoff_versions_match",
             "prd_has_required_sections",
-            "prd_snapshot_present"
+            "prd_snapshot_present",
+            "artifact_meta_complete",
+            "ids_valid",
+            "portal_index_fresh"
           ]
         },
         "args": {

package/framework/.claude/skills/build-product-prototype/SKILL.md

@@ -14,8 +14,8 @@ inputs:
 outputs:
   - "{process_slug}/pages/docs/fields.html"
   - "{process_slug}/pages/docs/ui-spec.html"
-  - "{process_slug}/designs/{design_id}/prototype.pen"
   - "{process_slug}/pages/prototype/**/*.html"
+  - "{process_slug}/designs/{design_id}/prototype.pen"
 required_tools:
   - Read
   - Bash

package/framework/.claude/skills/build-product-prototype/prompts/main.md

@@ -4,29 +4,16 @@ You are executing the Lincoln workflow step `product-prototype`: turn approved p
 
 ## Goal
 
-Create field and UI specifications as HTML doc pages, and produce a high-fidelity interactive HTML prototype that the PM can inspect directly in the issue-package portal (`{process_slug}/index.html`). A Pencil prototype is optional; the HTML prototype is the primary review artifact.
+Create field and UI specifications as HTML doc pages, and produce a high-fidelity interactive HTML prototype that the PM can inspect directly in the issue-package portal (`{process_slug}/index.html`). The HTML prototype is the primary review artifact; a Pencil prototype is optional and produced only if the PM explicitly asks for it.
 
 ## Reference templates
 
-Use the following read-only templates as the style/layout reference. Copy/adapt them into the issue package; do not modify the templates themselves.
-
-- `.claude/templates/issue-package/page-prototype.html.tpl` — minimal starter page with theme sync support.
-- `.claude/templates/issue-package/prototypes/app/main/page.html.tpl` — main app window with sidebar + WebView placeholder.
-- `.claude/templates/issue-package/prototypes/app/onboarding/page.html.tpl` — login/onboarding card.
-- `.claude/templates/issue-package/prototypes/app/settings/page.html.tpl` — two-column settings page.
-- `.claude/templates/issue-package/prototypes/app/overlays/page.html.tpl` — avatar menu / about / toast overlays.
-- `.claude/templates/issue-package/prototypes/app/tray/page.html.tpl` — system-tray scenario controller. When the product has a macOS menubar presence, create thin scenario pages under `pages/prototype/app/tray/` showing at minimum: default state, unread-badge state, and menu-open state. These pages must **not** redraw the tray inside the app prototype; instead they send `postMessage({type:'lincoln-tray-state', unread:<int>, open:<bool>}, '*')` to the portal so the portal-level macOS tray updates. See the tray template for the exact snippet.
-- `.claude/templates/issue-package/prototypes/app/org/page.html.tpl` — organization list.
-- `.claude/templates/issue-package/prototypes/web/dashboard/page.html.tpl` — web dashboard shell.
-- `.claude/templates/issue-package/prototypes/web/list/page.html.tpl` — web list view shell.
-- `.claude/templates/issue-package/prototypes/web/form/page.html.tpl` — web form shell.
-- `.claude/templates/issue-package/prototypes/web/detail/page.html.tpl` — web detail shell.
-- `.claude/templates/issue-package/prototypes/mobile/home/page.html.tpl` — mobile home feed shell.
-- `.claude/templates/issue-package/prototypes/mobile/chat/page.html.tpl` — mobile chat shell.
-- `.claude/templates/issue-package/prototypes/mobile/settings/page.html.tpl` — mobile settings list shell.
-- `.claude/templates/issue-package/prototypes/mobile/profile/page.html.tpl` — mobile profile shell.
-- `.claude/templates/issue-package/assets/prototype.css` — shared styles (tokens, dark mode, window shell, sidebar, forms, overlays, web/mobile shells).
-- `.claude/templates/issue-package/assets/prototype.js` — shared UI builders and mock data (`window.LincolnPrototype`), including `frameApp`, `frameWeb`, `frameMobile`.
+The default rendering templates are:
+
+- `.claude/templates/issue-package/page-doc-structured.html.tpl` — structured doc page used for `fields.html` and `ui-spec.html`.
+- `.claude/templates/issue-package/page-prototype-structured.html.tpl` — data-driven prototype page used for all `pages/prototype/**/*.html`.
+
+You may still read the categorized example templates under `.claude/templates/issue-package/prototypes/` for layout inspiration, but generate pages through `python scripts/lincoln_render.py` rather than copying templates by hand.
 
 ## Input
 
@@ -37,22 +24,98 @@ Use the following read-only templates as the style/layout reference. Copy/adapt
 
 1. Verify `{process_slug}/pages/docs/design-review.html` contains `<!-- status: approved -->` or `[x] PM 已确认设计文档`.
 2. Read the approved design package under `{process_slug}/pages/docs/`, including `flows.html` and `page-map.html`.
-3. Write `{process_slug}/pages/docs/fields.html` using `.claude/templates/issue-package/page-doc.html.tpl` with screen/form fields, data type, required/optional status, validation, default value, copy, error state, and source data object.
+3. Write `{process_slug}/pages/docs/fields.html` using the structured renderer:
+
+   ```bash
+   python scripts/lincoln_render.py \
+     --stage product-prototype \
+     --target {process_slug}/pages/docs/fields.html \
+     --title "字段说明" --nav-label "字段" --version v1.0 --uid fields \
+     --data {process_slug}/pages/docs/fields.yaml
+   ```
+
+   The YAML should contain a `fields` array (optionally grouped under `groups`):
+
+   ```yaml
+   intro: "本页面列出所有 screen/form 字段规格。"
+   annotations:
+     doc-purpose: "字段规格"
+     doc-fields: "字段名 — 类型 — 必填 — 说明"
+   fields:
+     - name: "手机号"
+       type: "string"
+       required: true
+       validation: "大陆手机号正则"
+       default: ""
+       copy: "请输入手机号"
+       error: "手机号格式不正确"
+       source: "model/user"
+   ```
+
 4. Write `{process_slug}/pages/docs/ui-spec.html` covering the interaction-document delivery standards:
    - 用户场景与流程: who, when, goal, trigger, completion criteria.
    - 界面流转图: screen-to-screen flow mapped to the business flow in `flows.html`.
    - 页面交互说明: per-screen layout elements, interaction rules (events, responses, navigation), and field validation/error handling.
    - 交互 Demo/原型: links to the HTML prototype pages under `pages/prototype/` and a summary of key interactions.
-5. **Plan prototype generation granularity.** Before writing prototype pages, list every screen from `flows.html` and `page-map.html`. Group them into cohesive clusters (e.g. onboarding, main shell, settings, overlays, tray). Generate one cluster at a time. After each cluster, verify that every page in the cluster has complete annotation meta tags before starting the next cluster. This prevents agent context exhaustion and keeps each page's documentation and interactions complete.
-6. Create interactive HTML prototypes under `{process_slug}/pages/prototype/{app,web,mobile}/` by adapting the reference templates above. Pick the right shell (`frameApp`, `frameWeb`, or `frameMobile`) from `LincolnPrototype.ui` for the product form-factor. Every page must:
+
+   Use the structured renderer with `--data` containing `sections`, `pages`, and `interactions` as appropriate.
+
+5. **Plan prototype generation granularity.** Before writing prototype pages, list every screen from `flows.html` and `page-map.html`. Group them into cohesive clusters (e.g. onboarding, main shell, settings, overlays, tray). Generate one cluster at a time. After each cluster, verify that every page has complete annotation meta tags before starting the next cluster.
+
+6. Create interactive HTML prototypes under `{process_slug}/pages/prototype/{app,web,mobile}/` using the structured prototype renderer:
+
+   ```bash
+   python scripts/lincoln_render.py \
+     --stage product-prototype \
+     --target {process_slug}/pages/prototype/web/dashboard/page.html \
+     --title "仪表盘" --nav-label "仪表盘" --nav-group "Prototype" --uid page-dashboard \
+     --data {process_slug}/pages/prototype/web/dashboard/page.yaml
+   ```
+
+   Prototype YAML schema:
+
+   ```yaml
+   layout:
+     type: web          # web | app | mobile
+     shell: dashboard   # dashboard | list | form | detail | main | onboarding | settings | overlays | tray | org
+     title: "仪表盘"
+     active: dashboard
+     navItems:
+       - {id: dashboard, label: 概览, href: ./dashboard/page.html}
+       - {id: list, label: 列表, href: ./list/page.html}
+   annotations:
+     doc-purpose: "展示核心指标与快捷入口"
+     doc-layout: "顶部导航 | 指标卡片网格 | 列表区"
+     doc-fields: "..."
+     doc-stories: "..."
+     doc-rules: "..."
+     doc-boundaries: "..."
+     doc-exceptions: "..."
+     doc-refs: "flows.html | page-map.html"
+   components:
+     - type: html
+       uid: dashboard-metrics
+       props:
+         html: '<div class="metric-grid">...'>
+     - type: wv
+       props:
+         kind: chat
+   interactions:
+     - trigger: "点击指标卡片"
+       action: "跳转到详情页"
+       target: "detail/page.html"
+   ```
+
+   Every page must:
    - Link to `../../../assets/prototype.css` and `../../../assets/prototype.js` (depth 3) or `../../../../assets/...` (depth 4) depending on its path.
-   - Include the theme sync IIFE shown in the starter template.
+   - Include theme sync support (built into the structured template).
    - Include `<meta name="prototype-base" content="../../../">` (or `../../../../` for depth 4).
-   - Include `<meta name="page-uid" content="...">`, `<meta name="nav-group" content="...">`, and `<meta name="nav-label" content="...">` with a short Chinese label for the left nav.
-   - Include the annotation meta tags `doc-purpose`, `doc-layout`, `doc-fields`, `doc-boundaries`, `doc-exceptions`. Also include `doc-stories`, `doc-rules`, `doc-refs` when they add clarity, so the portal right panel explains functionality, layout, fields, boundary cases, and exception flows.
+   - Include `<meta name="page-uid" content="...">`, `<meta name="nav-group" content="...">`, and `<meta name="nav-label" content="...">` (injected by the renderer from CLI args; annotations come from the YAML `annotations` block).
+   - Provide the full annotation meta tags so the portal right panel explains functionality, layout, fields, boundary cases, and exception flows.
    - Use `LincolnPrototype.ui` builders and `prototype.css` tokens for every visual element so both light and dark themes render correctly; verify both themes by toggling the portal theme switch.
    - Assign a stable `data-uid` attribute to every interactive element, screen region, and WebView placeholder.
    - Override `LincolnPrototype.data` in the page script for issue-specific mock data (user, org, webviews, settings, unread items).
+
 7. Optionally create or update `{process_slug}/designs/<design_id>/prototype.pen` with Pencil tools if the PM explicitly asks for a Pencil prototype. If you use Pencil tools, call `get_editor_state(include_schema: true)` first and use `snapshot_layout` to check for clipping/overlap.
 8. Update the root `{process_slug}/pages/docs/prd.html` section 9 "相关产物链接" with the `ui-spec.html`, `fields.html`, and HTML prototype links. If the PRD already has an approved snapshot, warn the PM that changes require a version bump and re-freeze via `python scripts/lincoln_prd.py freeze`.
 9. Ask the PM to open `{process_slug}/index.html` in a browser, toggle the theme switch in the macOS menubar, and review both light and dark renderings of each prototype page inside the portal.

package/framework/.claude/skills/clarify-requirements/prompts/main.md

@@ -20,24 +20,90 @@ Produce a clear, agreed-upon `{process_slug}/pages/docs/requirements.html` and t
 ## Steps
 
 1. Read `{process_slug}/interviews/<session-id>/transcript.md`, `summary.md`, and `raw-insights.md`.
-2. Draft an initial `{process_slug}/pages/docs/requirements.html` using `.claude/templates/issue-package/page-doc.html.tpl`. Embed the Markdown source in the `<script type="text/markdown" id="docSource">` block and include a `<!-- version: v1.0 -->` marker. Required sections:
-   - `背景`
-   - `问题`
-   - `用户`
-   - `方案`
-   - `验收标准`
-   - `非目标`
-   - `开放问题`
+2. Draft an initial `{process_slug}/pages/docs/requirements.html` using `python scripts/lincoln_render.py --stage clarify --target {process_slug}/pages/docs/requirements.html --title "需求文档" --nav-label "需求" --version v1.0 --uid requirements --data {process_slug}/pages/docs/requirements.yaml`. The YAML data file should follow this schema:
+
+   ```yaml
+   intro: "一句话概括本需求。"
+   annotations:
+     doc-purpose: "说明本次需求要解决的核心问题"
+     doc-layout: "单页文档"
+     doc-stories: "作为 <角色> 我想要 <目标> 以便 <价值>"
+     doc-rules: "列出关键业务规则"
+     doc-boundaries: "列出边界情况"
+     doc-exceptions: "列出异常流"
+   sections:
+     - title: "背景"
+       content: "..."
+     - title: "问题"
+       content: "..."
+     - title: "用户"
+       content: "..."
+     - title: "方案"
+       content: "..."
+     - title: "验收标准"
+       content: "..."
+     - title: "非目标"
+       content: "..."
+     - title: "开放问题"
+       content: "..."
+   ```
+
+   The renderer will inject the YAML as `pageData` and render structured sections automatically. You may also pass `--markdown` for a free-form supplement.
 3. Identify 1-3 ambiguities or missing details, and tag each with its Johari quadrant (认知象限): 知道自己知道 → 复述确认题; 知道自己不知道 → 直接回答 + coach; 不知道自己知道 → 展示已有资产; 不知道自己不知道 → 探查题.
 4. Ask the human PM these questions one batch at a time in the terminal, using the quadrant-appropriate style.
 5. Update `requirements.html` based on the answers (always rewrite the full file; do not mutate in-place).
 6. Repeat until the PM confirms the requirements are clear.
-7. Also generate `{process_slug}/pages/docs/user-stories.html` from the finalized requirements using the same doc-page template.
-8. Generate the root-level PRD at `{process_slug}/pages/docs/prd.html` using `.claude/templates/issue-package/page-doc.html.tpl`. It must include:
-   - `<!-- version: v1.0 -->` marker inside the `docSource` block.
-   - Meta tags: `doc-title`, `nav-group="Docs"`, `doc-version="v1.0"`, and a stable `doc-uid`.
-   - All required sections: 1.需求背景, 2.用户故事, 3.功能拆解, 4.业务流程图, 5.验收标准, 6.业务规则, 7.非功能需求, 8.关联系统/接口, 9.相关产物链接, 10.风险与开放问题.
-   - A links table in section 9 pointing to interviews, requirements.html, user-stories.html, and downstream design/prototype/OpenSpec artifacts.
+7. Also generate `{process_slug}/pages/docs/user-stories.html` from the finalized requirements using the structured renderer with `--data` containing a `stories` array:
+
+   ```yaml
+   intro: "基于已确认需求提炼的用户故事清单。"
+   annotations:
+     doc-purpose: "用户故事全景"
+   stories:
+     - who: "作为 访客用户"
+       want: "我想要 通过微信扫码登录"
+       so: "以便 不用注册密码"
+       acceptance: "扫码后 3 秒内完成登录"
+       source: "prd#section-2"
+   ```
+
+8. Generate the root-level PRD at `{process_slug}/pages/docs/prd.html` using the structured renderer with `--stage clarify --uid prd`. The data YAML must include `intro`, `annotations`, and `sections` for the 10 required PRD sections:
+
+   ```yaml
+   intro: "一句话 PRD 概述。"
+   annotations:
+     doc-purpose: "XXX 产品需求文档"
+     doc-stories: "..."
+     doc-rules: "..."
+     doc-boundaries: "..."
+     doc-exceptions: "..."
+     doc-refs: "requirements.html | user-stories.html"
+   sections:
+     - title: "1. 需求背景"
+       content: "..."
+     - title: "2. 用户故事"
+       content: "..."
+     - title: "3. 功能拆解"
+       content: "..."
+     - title: "4. 业务流程图"
+       content: "..."
+     - title: "5. 验收标准"
+       content: "..."
+     - title: "6. 业务规则"
+       content: "..."
+     - title: "7. 非功能需求"
+       content: "..."
+     - title: "8. 关联系统/接口"
+       content: "..."
+     - title: "9. 相关产物链接"
+       content: "| 产物 | 路径 | 状态 |"
+     - title: "10. 风险与开放问题"
+       content: "..."
+   ```
+
+   It must also carry:
+   - `<!-- version: v1.0 -->` marker (added automatically by the renderer from `--version`).
+   - Meta tags: `doc-title`, `nav-group="Docs"`, `doc-version="v1.0"`, and a stable `doc-uid` (all injected by the renderer).
 9. When the PM confirms, add an approval marker inside `requirements.html`: `<!-- status: approved -->`.
 10. After human approval, run `python scripts/lincoln_prd.py freeze` to create the immutable snapshot `{process_slug}/pages/docs/snapshots/prd-v1.0.html`.
 11. Run `python scripts/stage_loader.py --stage clarify --action record-artifacts` to persist the artifact paths and refresh `{process_slug}/assets/js/package-data.js`.

package/framework/.claude/skills/dependencies.yaml

@@ -45,6 +45,11 @@ skills:
     license: MIT
     required_skills:
       - gsd-import
+      - gsd-discuss-phase
+      - gsd-spec-phase
+      - gsd-ui-phase
+      - gsd-plan-phase
+      - gsd-mvp-phase
       - gsd-docs-update
       - gsd-forensics
       - gsd-ns-review
@@ -134,6 +139,7 @@ skills:
       - oh-my-claudecode:ralph
       - oh-my-claudecode:ultrawork
       - oh-my-claudecode:deep-interview
+      - oh-my-claudecode:designer
       - oh-my-claudecode:ai-slop-cleaner
       - oh-my-claudecode:wiki
       - oh-my-claudecode:writer-memory

package/framework/.claude/skills/draft-product-design/SKILL.md

@@ -21,7 +21,9 @@ outputs:
   - "{process_slug}/pages/docs/page-map.html"
   - "{process_slug}/pages/docs/version-log.html"
   - "{process_slug}/pages/docs/api-list.html"
+  - "{process_slug}/pages/docs/handoff-pm-to-ux-v*.html"
   - "{process_slug}/handoffs/pm-to-ux/pm-to-ux.handoff.yaml"
+  - "{process_slug}/handoffs/pm-to-ux/master-handoff-pm-to-ux-v*.md"
 required_tools:
   - Read
   - Bash

package/framework/.claude/skills/draft-product-design/prompts/main.md

@@ -1,10 +1,10 @@
 # draft-product-design
 
-You are executing the Lincoln workflow step `product-design-docs`: turn approved requirements into a concise product design review package for the human PM.
+You are executing the Lincoln workflow step `product-design-docs`: turn approved requirements into a concise product design review package (a set of HTML documents) for the human PM.
 
 ## Goal
 
-Create `{process_slug}/pages/docs/` HTML design documents with enough product, data, flow, feasibility, and technical framing for PM review and later development planning, without creating unnecessary review burden.
+Create `{process_slug}/pages/docs/` HTML design documents with enough product, data, flow, feasibility, and technical framing for PM review and later development planning, without creating unnecessary review burden. This step does **not** produce UI specs, field specs, or prototypes — those belong to the next stage `product-prototype`.
 
 ## Input
 
@@ -21,27 +21,40 @@ Create `{process_slug}/pages/docs/` HTML design documents with enough product, d
 
 1. Validate that `{process_slug}/pages/docs/requirements.html` is approved (contains `<!-- status: approved -->`).
 2. Read `{process_slug}/pages/docs/requirements.html`, `user-stories.html`, and the root-level `{process_slug}/pages/docs/prd.html`.
-3. Produce the design package under `{process_slug}/pages/docs/` using `.claude/templates/issue-package/page-doc.html.tpl`. Each page embeds Markdown in `<script type="text/markdown" id="docSource">` with a `<!-- version: v1.0 -->` marker and meta tags (`doc-title`, `nav-label`, `nav-group`, `doc-version`, `doc-uid`). Also include the annotation tags `doc-purpose`, `doc-layout`, `doc-fields`, `doc-boundaries`, `doc-exceptions` (and `doc-stories`, `doc-rules`, `doc-refs` when useful) so the portal right panel explains functionality, layout, fields, boundary cases, and exception flows:
-   - `design-review.html`: PM-facing entry point with decision summary, scope, links to all design docs, open questions, and approval checklist.
-   - `scenarios.html`: target users, primary scenarios, boundary scenarios, and non-goals.
-   - `feature-catalog.html`: concise feature list, priority, acceptance mapping, and source requirement links.
-   - `data-model.html`: core entities, fields, constraints, validation rules, and state transitions.
-   - `flows.html`: Mermaid user flow, business flow, screen flow, sequence diagram, and architecture diagram.
-   - `page-map.html`: page inventory, page relationships, navigation, and routing/state notes.
-   - `feasibility.html`: business feasibility, technical feasibility, current official framework/library options, usable open-source projects, risks, and recommended stack.
-   - `version-log.html`: design decision version history and rationale.
-   - `api-list.html`: internal and external APIs/data contracts the feature depends on.
+3. Produce the design package under `{process_slug}/pages/docs/` using `python scripts/lincoln_render.py --stage product-design-docs --target <path> --data <yaml>`. Each page uses the structured doc template; provide a YAML data file with `intro`, `annotations`, and the domain-specific keys below. The renderer injects the annotation metas (`doc-purpose`, `doc-layout`, `doc-fields`, `doc-boundaries`, `doc-exceptions`, plus `doc-stories`, `doc-rules`, `doc-refs` when useful) so the portal right panel explains functionality, layout, fields, boundary cases, and exception flows.
+
+   Common command pattern:
+   ```bash
+   python scripts/lincoln_render.py \
+     --stage product-design-docs \
+     --target issue-<N>/pages/docs/<page>.html \
+     --title "<标题>" --nav-label "<导航标签>" --version v1.0 --uid <uid> \
+     --data issue-<N>/pages/docs/<page>.yaml
+   ```
+
+   Page-specific data keys:
+   - `design-review.html`: `sections` (decision summary, scope, links, open questions, approval checklist).
+   - `scenarios.html`: `sections` plus optional `personas`, `primary`, `boundary`, `non_goals` arrays.
+   - `feature-catalog.html`: `features` array (`id`, `title`, `priority`, `acceptance`, `source`).
+   - `data-model.html`: `entities` array (`name`, `fields`, `constraints`, `states`).
+   - `flows.html`: `flows` array (`name`, `type`, `mermaid`, `steps`).
+   - `page-map.html`: `pages` array (`id`, `title`, `path`, `links`, `notes`).
+   - `feasibility.html`: `sections` plus `risks` and `options` arrays.
+   - `version-log.html`: `sections` plus `entries` array (`version`, `date`, `author`, `changes`, `rationale`).
+   - `api-list.html`: `apis` array (`name`, `method`, `endpoint`, `purpose`, `contract`).
 4. Create the PM→UX handoff contract at `{process_slug}/handoffs/pm-to-ux/pm-to-ux.handoff.yaml` referencing the approved design docs and PRD versions.
-5. Keep all documents traceable to the approved requirement and transcript timestamps where available.
-6. Update the root `{process_slug}/pages/docs/prd.html` section 9 "相关产物链接" with links to the new design documents. If the PRD already has an approved snapshot (`pages/docs/snapshots/prd-v*.html`), warn the PM that any content change requires bumping the version marker and re-freezing via `python scripts/lincoln_prd.py freeze`.
-7. Ask the PM to review `design-review.html` and linked docs (they can open `{process_slug}/index.html` in a browser).
-8. When the PM confirms, add `<!-- status: approved -->` to `design-review.html`.
-9. Run `python scripts/stage_loader.py --stage product-design-docs --action record-artifacts`.
+5. Create the human-readable PM→UX handoff portal page at `{process_slug}/pages/docs/handoff-pm-to-ux-v1.0.html` and the narrative master handoff document at `{process_slug}/handoffs/pm-to-ux/master-handoff-pm-to-ux-v1.0.md`. These summarize core decisions, scope, open questions, and the context pack for the receiving UX Agent.
+6. Keep all documents traceable to the approved requirement and transcript timestamps where available.
+7. Update the root `{process_slug}/pages/docs/prd.html` section 9 "相关产物链接" with links to the new design documents and handoff artifacts. If the PRD already has an approved snapshot (`pages/docs/snapshots/prd-v*.html`), warn the PM that any content change requires bumping the version marker and re-freezing via `python scripts/lincoln_prd.py freeze`.
+8. Ask the PM to review `design-review.html` and linked docs (they can open `{process_slug}/index.html` in a browser).
+9. When the PM confirms, add `<!-- status: approved -->` to `design-review.html`.
+10. Run `python scripts/stage_loader.py --stage product-design-docs --action record-artifacts`.
 
 ## Rules
 
 - Use Chinese for PM-facing content unless the requirements are in English.
 - Keep documents short and reviewable; prefer tables and Mermaid diagrams over long prose.
 - For technical frameworks and open-source projects, check current official docs or primary repositories before recommending.
+- Do not create UI specs, field specs, or prototypes in this step. Those are produced in the next stage `product-prototype`.
 - Do not create a Pencil prototype in this step.
 - After approval, tell the user to run: `claude build-product-prototype <session_id> <design_id>`.

package/framework/.claude/skills/lc-build-codebase-knowledge/SKILL.md

@@ -2,6 +2,8 @@
 name: lc-build-codebase-knowledge
 description: Use when starting Lincoln on an existing project with source code but no feature knowledge base yet.
 version: 1.0.0
+outputs:
+  - "knowledge/00-index.md"
 ---
 
 # Lincoln Build Codebase Knowledge

package/framework/.claude/skills/lc-explore-opensource/SKILL.md

@@ -2,6 +2,8 @@
 name: lc-explore-opensource
 description: Use during product design when the requirement can be solved or informed by existing open-source projects.
 version: 1.0.0
+outputs:
+  - "{process_slug}/docs/research/{change_name}-oss-options.md"
 ---
 
 # Lincoln Explore Open Source

package/framework/.claude/skills/lc-market-research/SKILL.md

@@ -9,7 +9,7 @@ inputs:
     description: 研究主题或产品决策背景
     required: false
 outputs:
-  - "{process_slug}/research/{session_id}/market-research.md"
+  - "{process_slug}/research/{session_id}/market.md"
 required_tools:
   - Bash
   - Read

package/framework/.claude/skills/lc-one-id/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: lc-one-id
+description: |
+  查询并维护 Lincoln one-id 索引，按功能点、页面、字段等 ID 定位相关产物。
+  当你需要追溯某个 feature/page/field/doc 对应的设计文档、字段规格、原型页或实现产物时，调用本 skill。
+triggers:
+  - "one-id"
+  - "lincoln_id"
+  - "按 id 查询"
+  - "feature 关联"
+  - "页面 id"
+  - "字段 id"
+inputs:
+  - name: query
+    description: |
+      自然语言查询或 exact CLI 子命令。
+      例如：
+      - "lookup page/web-dashboard"
+      - "related feature/checkout-redesign"
+      - "list --type field"
+      - "create page/list-page --title 列表页 --path issue-9999-test/pages/prototype/web/list/page.html"
+    required: true
+outputs:
+  - one-id 条目详情或关联产物路径列表
+required_tools:
+  - Bash
+  - Read
+---
+
+# lc-one-id
+
+## Purpose
+
+Using [lc-one-id] to 查询并维护 Lincoln one-id 索引。
+
+one-id 是 Lincoln 跨阶段追溯的核心机制：PM/UX 阶段为页面、功能点、字段等建立稳定 ID，UE、研发、QA 阶段通过该 ID 查找相关产物，而不是凭路径猜测。
+
+one-id 索引文件位于 `{process_slug}/.lincoln/one-id/` 下，由 `scripts/lincoln_id.py` 管理。
+
+## When to use
+
+-  downstream 阶段（TDD 计划、实现、验收）需要确认某个 feature/page/field 的上游产物。
+-  创建或更新 one-id 条目时。
+-  检查某个 ID 是否已存在或查找关联项时。
+
+## How to use
+
+本 skill 会把你的 `query` 解析为 `scripts/lincoln_id.py` 命令，并通过 Bash 执行。
+
+常用命令：
+
+- 查询单个条目：
+  ```bash
+  scripts/lincoln_id.py lookup <type>/<id>
+  ```
+
+- 查询某个条目的所有关联项：
+  ```bash
+  scripts/lincoln_id.py related <type>/<id>
+  ```
+
+- 按类型列出所有条目：
+  ```bash
+  scripts/lincoln_id.py list --type <page|feature|field|doc>
+  ```
+
+- 创建或更新条目：
+  ```bash
+  scripts/lincoln_id.py create <type>/<id> \
+    --title "<title>" \
+    --path "<relative-path>" \
+    --source "<origin>" \
+    --relation "<type>/<id>"
+  ```
+
+`scripts/lincoln_id.py` 会自动发现当前工作区最新的 `issue-*/workflow-stage.yaml`，本 skill 不传递 `--state-file`。如果自动发现指向了错误的 issue 包，先让目标包成为最新 mtime，或清理旧沙盒包。
+
+## Output handling
+
+- 如果查询成功，返回条目 YAML 内容或关联列表，并据此读取对应产物文件。
+- 如果 ID 不存在或类型非法，脚本会返回非零退出码；此时应向用户汇报，而不是继续基于缺失信息推进。