npm - pi-feishu-cli - Versions diffs - 0.1.0 - Mend

pi-feishu-cli 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (407) hide show

package/skills/lark-slides/references/troubleshooting.md ADDED Viewed

@@ -0,0 +1,198 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <link rel="icon" href="favicon.ico" />
+  <title></title>
+  <style>
+      * {
+          box-sizing: border-box;
+          padding: 0;
+          margin: 0;
+      }
+      .open-platform-wrapper {
+          display: flex;
+          flex-direction: column;
+          align-items: center;
+          justify-content: center;
+          height: 100vh;
+          background-color: #ffffff;
+      }
+      .open-platform-icon {
+          width: 120px;
+          height: 120px;
+          display: block;
+      }
+      .open-platform-desc {
+          margin-top: 16px;
+          line-height: 22px;
+          font-size: 14px;
+          color: #646a73;
+          text-align: center
+      }
+      .open-platform-back {
+          border-radius: 6px;
+          font-size: 14px;
+          height: 32px;
+          line-height: 22px;
+          min-width: 80px;
+          padding: 4px 11px;
+          text-align: center;
+          text-decoration: none;
+          touch-action: manipulation;
+          transition: color .1s ease-in, background-color .1s ease-in, border-color .1s ease-in, width .2s ease-in;
+          user-select: none;
+          white-space: nowrap;
+          background: #1456f0;
+          border: 1px solid #1456f0;
+          color: #ffffff;
+          margin-top: 16px;
+      }
+  </style>
+</head>
+<body>
+<div class="open-platform-wrapper">
+  <img class="open-platform-icon"
+       src="data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMTIwIiBoZWlnaHQ9IjEyMCIgdmlld0JveD0iMCAwIDEyMCAxMjAiIGZpbGw9Im5vbmUiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHBhdGggZD0iTTEyLjkxMyA1NS4yNDRjLTUuNjMyIDIuOTUtOC4yNDYgNi4yODQtOC4yNDYgOS40NHY5LjcyYzAtMy4xNTYgMi42MTQtNi40OSA4LjI0Ni05LjQ0di05LjcyWm05NC4xNjMtMTIuMDg0di05LjcyNmM1LjkzNC0zLjE5IDguOTgxLTYuODkxIDguOTgxLTEwLjcyNXY5LjcyYzAgMy44NC0zLjA0NyA3LjU0My04Ljk4MSAxMC43MzJaIiBmaWxsPSIjMEMyOTZFIi8+PHBhdGggZD0iTTYwLjIyOSAxOS4wNTkgNDguNzMgNDkuOTIyIDYwLjM2NSA3Mi45MmwtOC40NzQgMjMuODczSDE2LjkyM2E0IDQgMCAwIDEtNC00VjIzLjA2YTQgNCAwIDAgMSA0LTRINjAuMjNaIiBmaWxsPSIjQkJCRkM0IiBmaWxsLW9wYWNpdHk9Ii40NSIvPjxwYXRoIGQ9Ik03MS40MDggMTkuMDU5IDYwLjAxMyA0OS45MjIgNzEuNDYgNzIuOTJsLTguMzI1IDIzLjg3M2gzOS45NDNhNCA0IDAgMCAwIDQtNFYyMy4wNmE0IDQgMCAwIDAtNC00aC0zMS42N1oiIGZpbGw9IiNCQkJGQzQiIGZpbGwtb3BhY2l0eT0iLjQ1Ii8+PHBhdGggZD0iTTIxLjkyMyAyNi4xYTIgMiAwIDEgMSAwIDQgMiAyIDAgMCAxIDAtNFptMyAyYTMgMyAwIDEgMC02IDAgMyAzIDAgMCAwIDYgMFptNi45MTUtMmEyIDIgMCAxIDEgMCA0IDIgMiAwIDAgMSAwLTRabTMgMmEzIDMgMCAxIDAtNiAwIDMgMyAwIDAgMCA2IDBabS0xNS43NjMgNy4zOTRhLjUuNSAwIDAgMSAuNS0uNWgzMS41ODFhLjUuNSAwIDAgMSAwIDFIMTkuNTc1YS41LjUgMCAwIDEtLjUtLjVabTQ4LjQ3NyAwYS41LjUgMCAwIDEgLjUtLjVoMzIuNDY1YS41LjUgMCAwIDEgMCAxSDY4LjA1MmEuNS41IDAgMCAxLS41LS41WiIgZmlsbD0iIzhGOTU5RSIvPjxwYXRoIGQ9Ik05OCAxMTFjOS45NDEgMCAxOC04LjA1OSAxOC0xOHMtOC4wNTktMTgtMTgtMThjLTkuOTQyIDAtMTggOC4wNTktMTggMThzOC4wNTggMTggMTggMThaIiBmaWxsPSIjRjgwIi8+PHBhdGggZD0iTTk3LjE4MSA4NC44MThhLjgxOC44MTggMCAwIDAtLjgxOC44MTl2OS44MThjMCAuNDUyLjM2Ni44MTguODE4LjgxOGgxLjYzN2EuODE4LjgxOCAwIDAgMCAuODE4LS44MTh2LTkuODE5YS44MTguODE4IDAgMCAwLS44MTgtLjgxOEg5Ny4xOFptMCAxMy4wOTJhLjgxOC44MTggMCAwIDAtLjgxOC44MTh2MS42MzZjMCAuNDUyLjM2Ni44MTguODE4LjgxOGgxLjYzN2EuODE4LjgxOCAwIDAgMCAuODE4LS44MTh2LTEuNjM2YS44MTguODE4IDAgMCAwLS44MTgtLjgxOUg5Ny4xOFoiIGZpbGw9IiNmZmYiLz48cGF0aCBkPSJNNC4wMjcgODUuMzFjMi40OSA1LjUxIDE0Ljc3IDkuOTQgNDEuNDUgOS45M3Y5LjcyMWMtMjYuNjguMDEtMzguOTYtNC40Mi00MS40NS05Ljkzdi05LjcyWm04NC44MS0yNy4yN2MxNy41Mi0yLjY5IDI1LjgwNy03LjAyNiAyNy4yLTExLjcxdjkuNzJjLS4zMyA0LjY3LTkuNjggOS4wMi0yNy4yIDExLjcxdi05LjcyWiIgZmlsbD0iIzMzNzBGRiIvPjxwYXRoIGQ9Ik04OS4yMzcgMTMuMDFjMTguMDU4IDAgMjYuOCAzLjI1IDI2LjggOS43MnY5LjcyYzAtNi40Ny04Ljc0Mi05LjcyLTI2LjgtOS43MnYtOS43MlptLTg0LjU3IDUxLjdjMCA2LjYgMTEuMzcgMTIuNDUgMzAuNDcgMTIuNDR2OS43MmMtMTkuMSAwLTMwLjQ3LTUuODQtMzAuNDctMTIuNDR2LTkuNzJaIiBmaWxsPSIjMDBENkI5Ii8+PC9zdmc+"
+       alt="">
+  <div class="open-platform-desc">The page does not exist.</div>
+  <a class="open-platform-back" href="/">Go to homepage</a>
+</div>
+<script>window.gfdatav1={"env":"prod","ver":"1.0.0.13","canary":0,"garrModules":null,"envName":"prod","region":"CN","idc":"hl","webServerCodeType":"DeployServerlessWebServer","runtime":"node","extra":{"canaryType":null}}</script><script>
+  function parseQueryString(queryString) {
+    // 移除开头的 "?"
+    if (queryString.charAt(0) === '?') {
+      queryString = queryString.substring(1);
+    }
+    var params = {};
+    if (!queryString) return params;
+    // 分割参数对
+    var paramPairs = queryString.split('&');
+    for (var i = 0; i < paramPairs.length; i++) {
+      var paramPair = paramPairs[i].split('=');
+      var key = decodeURIComponent(paramPair[0]);
+      var value = paramPair.length > 1 ? decodeURIComponent(paramPair[1]) : '';
+      // 处理重复参数（转为数组）
+      if (params[key] === undefined) {
+        params[key] = value;
+      } else if (!Array.isArray(params[key])) {
+        params[key] = [params[key], value];
+      } else {
+        params[key].push(value);
+      }
+    }
+    return params;
+  }
+  function getLocale() {
+    var zhLang = 'zh-CN';
+    var enLang = 'en-US';
+    var queryLang = parseQueryString(window.location.search).lang;
+    var cookieLang = getCookieLocale();
+    var lang = enLang;
+    <!--从cookie中取值-->
+    function getCookieLocale() {
+      var locale = '';
+      var cookies = document.cookie.split('; ');
+      var loclaeKey = 'open_locale';
+      for (var i = 0; i < cookies.length; i++) {
+        var cookie = cookies[i].trim();
+        var cookieArr = cookie.split('=');
+        if (cookieArr[0] === loclaeKey) {
+          locale = cookieArr[1];
+          break;
+        }
+      }
+      return locale;
+    }
+    function setLocaleCookie(lang) {
+      var date = new Date();
+      // 300天到期
+      date.setTime(date.getTime() + (300 * 24 * 60 * 60 * 1000));
+      var expires = 'expires=' + date.toUTCString();
+      document.cookie = 'open_locale=' + lang + '; ' + expires + '; path=/;';
+    }
+    // 获取浏览器默认语言
+    if (navigator.language.indexOf('en') !== -1) {
+      lang = enLang;
+    } else if (navigator.language.indexOf('zh') !== -1) {
+      lang = zhLang;
+    }
+    if (cookieLang === enLang) {
+      lang = enLang;
+    } else if (cookieLang === zhLang) {
+      lang = zhLang;
+    }
+    if (queryLang === enLang) {
+      lang = enLang;
+    } else if (queryLang === zhLang) {
+      lang = zhLang;
+    }
+    // 设置cookie
+    setLocaleCookie(lang);
+    return lang;
+  }
+  // 根据域名获取当前brand
+  function isLarkDomain() {
+    var defaultBrandMap = {
+      lark: ['larksuite'],
+      feishu: ['feishu', 'larkoffice', 'larkenterprise'],
+    };
+    const { hostname } = window.location;
+    if (defaultBrandMap.feishu.some((item) => hostname.includes(item))) {
+      return false;
+    }
+    if (defaultBrandMap.lark.some((item) => hostname.includes(item))) {
+      return true;
+    }
+    if (window.domainBrand) {
+      return window.domainBrand === 'lark';
+    }
+    return false;
+  }
+  var isLarkBrand = isLarkDomain();
+  var config = {
+    'zh-CN': {
+      'desc': '抱歉，您访问的页面不存在',
+      'back': '返回首页',
+      'title': (isLarkBrand ? 'Lark' : '飞书') + '开放平台',
+    },
+    'en-US': {
+      'desc': 'The page does not exist.',
+      'back': 'Go to homepage',
+      'title': (isLarkBrand ? 'Lark': 'Feishu') + ' Open Platform',
+    },
+  };
+  var locale = getLocale();
+  var descObj = document.querySelector('.open-platform-desc');
+  var backObj = document.querySelector('.open-platform-back');
+  descObj.innerHTML = config[locale].desc;
+  backObj.innerHTML = config[locale].back;
+  document.title = config[locale].title;
+</script>
+</body>
+</html>

package/skills/lark-slides/references/validation-checklist.md ADDED Viewed

@@ -0,0 +1,102 @@
+# Validation Checklist
+创建或大幅改写演示文稿后，必须做一次显式验证。目标是发现空白页、XML 损坏、内容截断、明显溢出、弱视觉层级和未验证输出。
+小型已有页编辑也要做对应范围的验证：至少读取被改页面或全文 XML，确认目标元素已更新且未破坏周边结构。
+## Required Flow
+1. 记录创建或编辑返回的 `xml_presentation_id`，以及已知的 `slide_id` / `revision_id`。
+2. 用 `xml_presentations.get` 回读全文 XML。
+3. 检查实际页数是否符合计划或用户要求。
+4. 检查每页 `<data>` 内是否有预期主要元素。
+5. 检查没有明显空白页、破损页、缺失标题或缺失主视觉。
+6. 检查页面不是全部退化为标题加 bullet list。
+7. 检查视觉层级：标题、主视觉、支撑信息三者可区分。
+8. 检查明显溢出和布局风险：重叠、越界、底部拥挤、长文本框。
+9. 在最终回复中给出简短验证记录。
+回读命令：
+```bash
+lark-cli slides xml_presentations get --as user \
+  --params '{"xml_presentation_id":"YOUR_ID"}'
+```
+## Automated XML Text Overlap Lint
+回读 XML 保存到本地文件后，优先运行 XML 语法和文本重叠静态检查：
+```bash
+python3 skills/lark-slides/scripts/xml_text_overlap_lint.py --input <presentation.xml>
+```
+通过标准：
+- `summary.error_count == 0`。任何 error 都必须先修复再交付。
+- 当前工具只检查 XML well-formed 和文本元素之间的明显重叠；它不检查越界、文本高度不足、图文压盖、表格/图表压盖或底部拥挤。
+- 该工具不能替代页数核对、关键内容核对或真实视觉验收。
+常见 code 的处理方向：
+| code | 含义 | 处理方式 |
+|------|------|----------|
+| `xml_not_well_formed` | XML 语法错误或文本未转义 | 修复标签闭合、属性引号、`&` / `<` / `>` 转义 |
+| `bbox_overlap` | 文本元素的估算绘制区域明显重叠 | 拉开文本坐标、缩小文本框/字号，或改成明确的分栏/分组结构 |
+## Page Count And Structure
+- 实际页数必须等于用户要求或 `slide_plan.json` 的页数。
+- 如果创建过程部分失败，先记录已创建的 `xml_presentation_id`，再回读确认哪些页已写入。
+- 每页都应包含 `<data>`，且 `<data>` 内至少有一个非背景主体元素。
+- 封面、章节页、总结页可以文字较少，但不能只有空背景。
+- 技术解释页、对比页、流程页、架构页必须有匹配的结构元素，例如分组框、连线、时间轴、表格或图形化区域。
+## Expected Elements
+按 `slide_plan.json` 和用户要求逐页核对：
+- 标题或主结论存在，并能对应 `key_message`。
+- `layout_type` 对应的主要结构已生成。
+- `visual_focus` 是页面中最醒目或最大的信息区域之一。
+- `text_density` 影响了文本量，没有用长 bullet 框替代规划。
+- `asset_need` 有真实素材时已放入正确区域；没有真实素材时，`fallback_if_missing` 已用 XML 形状、线条、标签、表格或图表兜底。
+如果用户指定了关键页，例如“架构解释”“Self-Attention 机制解释”“对比或演进视角”“总结页”，最终验证记录必须逐项说明这些页已存在。
+## Blank Or Broken Page Signals
+把下面情况视为需要修复后再交付：
+- `<data/>` 为空，或只有背景、装饰线、空 `<content/>`。
+- 关键文本没有出现在回读 XML 中。
+- 图片仍是 `@./path`，或 `<img src>` 是 http(s) 外链。
+- 页面依赖的图片区域为空，且没有 fallback visual。
+- 返回 XML 缺页、页序明显错误，或某页内容被 shell 截断。
+- 大量形状坐标完全相同，导致主体内容重叠。
+- 渐变背景回退成空白或白底，导致文字不可读。
+## Layout And Overflow Risk
+优先修复这些明显风险：
+- 正文或标签框高度不足，文本很可能被截断。
+- 多个主体元素在同一区域重叠，而不是有意叠加背景。
+- 重要内容越过画布边界，或贴近底部超过 `y=500`。
+- 高密度页使用单个长 bullet list，没有分栏、表格或分组。
+- 标题、主视觉、正文的字号和颜色差异太弱，视觉层级不清。
+- 所有内容页都是同一套标题加 bullets 坐标。
+## Verification Record
+最终回复必须包含简短验证记录，建议格式：
+```text
+验证记录：
+- 回读：已执行 xml_presentations.get，实际页数 N / 预期 N。
+- 关键页：架构解释 / Self-Attention / 对比或演进 / 总结页均存在。
+- 结构：检查了主要 shape/img/table/chart 元素，无明显空白页或破损页。
+- 布局：检查了标题层级、主视觉、重叠/越界/文本溢出风险。
+```
+不要声称完成了人工视觉验收，除非确实打开或获取了可视化结果。仅从 XML 静态检查得出的结论，应表述为“静态检查未发现明显问题”。

package/skills/lark-slides/references/visual-planning.md ADDED Viewed

@@ -0,0 +1,250 @@
+# Visual Planning
+新建演示文稿或大幅改写页面时，在 `slide_plan.json` 完成后、生成 XML 前读取本文件。目标是让 `layout_type`、`visual_focus`、`text_density` 变成实际页面几何，而不是只写在 plan 里。
+默认画布按 `960 x 540` 规划。模板 XML 可以覆盖具体坐标，但不能覆盖这些原则：页面要有主视觉区域、文本要受密度约束、不同 `layout_type` 必须产生明显不同的坐标结构。
+## Core Rules
+- `layout_type` must change geometry: element positions, region sizes, alignment, and visual rhythm must differ across page types.
+- `visual_focus` determines the largest or highest-contrast region. It can be an image, diagram, metric, quote, table, or shape-based placeholder.
+- `text_density` caps visible text:
+  - `low`: title plus one short statement, or 1-3 labels.
+  - `medium`: title plus 2-4 concise bullets or labeled regions.
+  - `high`: use a table, columns, grouped labels, or annotations. Do not use one long bullet box.
+- Do not create a deck where every content page is title plus bullets. For 4 or more pages, use at least 4 different layout structures when the content allows.
+- Keep generous margins. Use `60-80` px outer margins on standard content pages unless a full-bleed image or cover treatment is intentional.
+- Reserve vertical space for titles. A typical content title area is `y=36..90`; main content should usually start at `y>=110`.
+- Avoid crowding the bottom edge. Keep non-background content above `y=500` unless it is a footer.
+- Prefer fewer, larger objects over many small text boxes.
+- Keep backgrounds consistent with the deck's `visual_system.background_strategy`. Normal content pages should use the same base background unless there is a clear page-role reason to change.
+- Treat text fit as a layout constraint, not a cleanup step. If a text box is too small for the intended line count, shorten the text, split it, or allocate more space before creating XML.
+## Background And Motif Consistency
+Decks can vary page backgrounds, but variation must be intentional and legible:
+- Pick one default background for ordinary content pages and reuse it exactly. Avoid near-identical drift such as several slightly different off-white values unless it encodes a clear section change.
+- Cover, section divider, emphasis, and conclusion pages may use a dark, image-led, or high-contrast background. They must still share the deck's primary color, motif, edge treatment, typography, or geometry.
+- If a cover uses a split composition, make the split visible in the background or layout. For example, reserve a darker text region and a related but distinct visual region instead of placing all elements on one flat field.
+- Reuse a small number of visual devices: side bar, card radius, node style, line weight, icon container, or footer treatment. Do not introduce a new decorative language on each page.
+- Insert background and motif shapes before content elements so they do not cover text, images, or diagrams.
+## Text Fit Guardrails
+Use these as conservative minimums on a 960 x 540 canvas. Increase height when using bold text, Chinese text, mixed Chinese/English, or line spacing above default.
+| Text use | Typical font size | Minimum height |
+|----------|-------------------|----------------|
+| Caption, 1 line | 10-12 | 18 |
+| Caption, 2 lines | 10-12 | 30 |
+| Body, 1 line | 13-16 | 24 |
+| Body, 2 lines | 13-16 | 40 |
+| Body, 2 lines, bold | 15-18 | 48 |
+| Headline, 1 line | 24-32 | 42 |
+| Title, 2 lines | 34-44 | 110 |
+Additional rules:
+- Do not put long Chinese sentences or long English phrases into `height=18` or `height=22` boxes. Those heights are for short labels only.
+- Footer/source text should usually be one short line. If it needs more, make it a real caption block above the footer area.
+- Bottom conclusion bars should be at least `40` px tall for one emphasized line and at least `54` px tall for two lines.
+- Diagram labels should be short enough to fit the shape. Prefer two short lines over one cramped long line.
+- When a text block has more than one `<p>`, size the box for multiple lines explicitly. Do not assume the renderer will auto-expand.
+- If a line contains mixed Chinese and English, budget more width than either language alone; mixed text wraps less predictably.
+## Layout Types
+### `title-cover`
+Purpose: introduce the deck's point of view.
+Geometry:
+- Use one dominant title block, usually `x=70..120`, `y=150..250`, `width=700..820`.
+- Add one subtitle or context line, not a bullet list.
+- Optional visual focus can be a full-bleed background, large side image, accent band, or abstract shape motif.
+- If the cover has a right-side diagram, screenshot, or motif cluster, use a split layout: keep the title/subtitle region within the left or central text region, and reserve a separate visual region so labels and connectors do not cross the title.
+- For split covers, make the background reinforce the composition, such as a darker text side and a related visual panel. Avoid one flat field where title and diagram compete for attention.
+- Keep source metadata to one short line where possible. If it wraps, shorten author lists or move details to notes.
+- The main title should be controlled, normally one or two lines. Do not let it occupy both the text region and the visual region.
+Text:
+- `low` only unless the user explicitly asks for detail.
+### `section-divider`
+Purpose: reset rhythm and mark a new chapter.
+Geometry:
+- Use a large section number, chapter label, or single centered claim.
+- Keep the page sparse. A divider is not a content page.
+- Visual focus can be one oversized number, a vertical accent bar, or a full-width band.
+Text:
+- Title plus one phrase. No bullets.
+### `two-column`
+Purpose: compare two related ideas or pair explanation with evidence.
+Geometry:
+- Split main region into two balanced columns, for example left `x=60,width=400`, right `x=500,width=400`.
+- Each column needs its own heading or visual anchor.
+- Do not place one full-width bullet box under a normal title; that is not a two-column layout.
+Text:
+- `medium`: 2-3 short items per column.
+- `high`: use grouped rows or mini table structure inside columns.
+### `image-left-text-right`
+Purpose: let a visual establish context, with text explaining implication.
+Geometry:
+- Left visual region should occupy roughly `35-45%` of slide width, often full height or tall crop.
+- Right text region starts around `x=420` and should have a strong headline plus short support.
+- If no real image is available, create a shape-based placeholder visual that matches `asset_need`.
+- For dense screenshots, paper figures, or product captures with small labels, allocate a larger visual region when possible: often `50-65%` of slide width or at least `320` px height.
+- Place screenshots in a deliberate frame or panel, and leave enough margin so axes, captions, and edge labels are not cropped by the slide boundary.
+Text:
+- Keep right-side text short. Avoid more than 4 bullets.
+- For screenshot explanation pages, prefer 2-3 interpretation cards or callouts instead of a paragraph block.
+### `image-right-text-left`
+Purpose: lead with a message, then reinforce it with a visual.
+Geometry:
+- Left text region starts around `x=60..90`, width `400..460`.
+- Right visual region occupies roughly `35-45%` of slide width.
+- Align the image or placeholder with the main text block, not only with the title.
+- For dense screenshots, paper figures, or product captures with small labels, increase the visual region and reduce text. A readable image is more valuable than a fully populated text column.
+Text:
+- Use one main claim and 2-3 supporting points.
+- Keep callouts parallel and short. If a callout needs more than two lines, split it into a separate note or a new slide.
+### `big-number`
+Purpose: make one metric or fact memorable.
+Geometry:
+- Reserve the largest object for the metric: font size often `64-110`, region at least `300 x 120`.
+- Pair the number with one explanation and optional 2-3 small supporting labels.
+- Do not bury the number in a bullet list or small card.
+Text:
+- `low` or `medium`. If detail is needed, add small annotations around the metric.
+- Supporting labels must not compete with the number. Use compact labels, legends, or mini-cards rather than long explanatory bars.
+### `timeline`
+Purpose: show sequence, roadmap, history, or phases.
+Geometry:
+- Create a horizontal or vertical spine with 3-6 milestones.
+- Each milestone should have a dot/card/date label connected by a line or arrow.
+- Title is separate from the sequence. The sequence is the visual focus.
+Text:
+- Each milestone gets a short label and optional one-line explanation.
+- Do not use paragraph-length milestone descriptions.
+### `comparison`
+Purpose: make a choice, before/after, old/new, or option tradeoff clear.
+Geometry:
+- Use two or three distinct panels, columns, or a table-like structure.
+- Headings must be visually aligned so differences are easy to scan.
+- Use color, border, icon, or label treatment to highlight the preferred option or key difference.
+Text:
+- Use parallel wording across columns.
+- Avoid uneven long bullet lists that destroy comparability.
+### `architecture-diagram`
+Purpose: explain components, dependencies, or system flow.
+Geometry:
+- Main visual area should be a diagram, not prose.
+- Use grouped boxes, lanes, arrows or lines, and short labels.
+- Keep diagram labels concise. Put explanation in notes or a small side caption if needed.
+Text:
+- Prefer labels of 1-5 words.
+- Use no more than one short explanatory text block.
+- If a node label needs two lines, size the node and the text box for two lines. Do not let labels overlap connectors.
+### `process-flow`
+Purpose: show operational steps, workflow, or cause-effect path.
+Geometry:
+- Use numbered steps connected by arrows or lines.
+- 3-5 steps is ideal for one slide. If there are more, group them into phases.
+- The flow direction must be visually obvious.
+Text:
+- Each step gets a verb-led label and one short descriptor at most.
+- Step labels should be parallel in length and grammar. If one step needs a long explanation, move the explanation to a side note or speaker notes.
+### `quote-highlight`
+Purpose: emphasize a customer voice, principle, thesis, or decision statement.
+Geometry:
+- Quote or claim is the dominant text object.
+- Use large type, generous whitespace, and optional attribution or context badge.
+- Do not combine a quote-highlight page with a normal bullet section.
+Text:
+- One quote or statement, plus optional attribution. No bullets.
+### `conclusion`
+Purpose: close with decision, recommendation, or next action.
+Geometry:
+- Use one dominant closing statement or call to action.
+- Add up to 3 next-step cards, checklist items, or owner/date labels.
+- Visual focus should be the recommendation or action, not decorative filler.
+Text:
+- Keep the final page easy to remember. Avoid recap overload.
+- Conclusion pages may mirror the cover background, but must clearly reuse the deck's motif or color roles so the ending feels intentional.
+## Screenshot And Paper Figure Pages
+When a page uses a real screenshot, chart, paper figure, or product capture:
+- Choose screenshot placement based on page role, not a fixed slide number. Method overview, evidence, comparison, and failure-analysis pages are common candidates; title, agenda, and conclusion pages usually are not.
+- Use the real asset only when it is readable at slide size. If the figure is too dense, crop to the relevant region, create a zoomed detail, or redraw the core message with native shapes.
+- A screenshot should normally be the visual focus. Do not shrink it into a decorative thumbnail while surrounding it with dense text.
+- Pair the image with a small number of interpretive annotations that tell the audience what to notice.
+- Always include a short source caption when using external or paper-derived visuals.
+- Verify the final XML contains a supported image token or creation-time local placeholder, not an unsupported external URL.
+## Plan To XML Checklist
+Before creating XML for each page, answer these checks:
+1. Which region is the visual focus, and is it the largest or most prominent object?
+2. Does the XML geometry match the `layout_type` description above?
+3. Does `text_density` limit the number of paragraphs, bullets, labels, and text boxes?
+4. Would this page still be recognizable if the `layout_type` label were removed from the plan?
+5. Across the deck, do multiple pages use genuinely different structures?
+6. Does the background follow the planned deck strategy, and are any deviations intentional?
+7. Are all text boxes large enough for their intended font size and line count?
+8. If the page uses a screenshot or paper figure, is it large enough to read and accompanied by concise interpretation?
+After fetching the created presentation, verify:
+- Use `timeline`, `comparison`, and `architecture-diagram` only when the content calls for them; do not force irrelevant page types.
+- Any planned `timeline`, `comparison`, or `architecture-diagram` page uses the matching sequence, side-by-side comparison, or component-and-connection structure.
+- Pages are not crowded and do not rely on long bullet boxes.
+- Main claim, supporting detail, and visual focus have clear hierarchy.
+- Static XML inspection should include text-fit risk: very short text boxes containing long text, multi-paragraph boxes with insufficient height, footer text that may wrap, and labels placed directly over connectors.
+- Background and motif consistency should be checked across pages, not only within one slide.