@shulex/cxclawctl 0.1.2 → 0.1.4

package/skills/solvea-desk/SKILL.md

@@ -1,39 +0,0 @@
----
-name: solvea-desk
-description: 查询、分析和管理 Shulex Desk / Tars 工单；支持当前工单筛选、历史报表及工单标签查询、绑定和解绑。
-requires:
-  libs: []
----
-
-# Shulex Desk
-
-Shulex Desk / Tars 客服台工单的唯一入口。它与 GPT 标签树配置、CX 产品售后工单是不同的数据和操作面，不要混用。
-
-## 场景路由
-
-| 用户诉求 | 必读文档 |
-|---|---|
-| 当前工单列表、筛选、正文分类 | `/skills/solvea-desk/references/tickets/query.md` |
-| 标签树、工单标签、绑定或解绑 | `/skills/solvea-desk/references/tickets/tags.md` |
-| 指标、趋势、时效、明细、XLSX 或报表 | `/skills/solvea-desk/references/report/workflow.md` |
-
-## 共用约束
-
-- 查询和修改只使用上述文档指定的受控脚本，不直接 curl Tars 接口。
-- 标签写入前必须确认目标工单和当前标签，并通过标签树或搜索获得准确的 Tars 标签 ID；不得使用 GPT 标签树 ID，也不得根据名称猜 ID。
-- 向用户展示工单号、操作类型、标签名称和 ID，获得明确确认后才能向脚本传 `--confirm`。
-- `aiTags` 只读；绑定和解绑只操作并核验 `userTags`。
-- 搜索返回多个同名或相近标签路径时让用户选择，不自动取第一个。
-- 新任务只写 `/workspace/state/solvea-desk/`、`/workspace/outputs/solvea-desk/` 和 `/workspace/tmp/solvea-desk/`。
-
-## 历史报表任务
-
-先读取 `/workspace/state/solvea-desk/latest_task.json`。新路径不存在时，可以**只读**检查 `/workspace/state/desk-report/latest_task.json` 及其 task 目录，以继续分析或重新渲染旧任务。
-
-历史回退仅用于读取：任何新任务和新 fetch 都必须写入 `/workspace/state/solvea-desk/`，不得向旧 `desk-report` 目录写入。
-
-## 相邻能力边界
-
-- GPT 标签树、标签组、标签节点配置：使用 `solvea-kit`，接口位于 `/api_v2/gpt/label/project/...`。
-- CX 产品售后咨询、创建或追加售后工单：使用 `shulex-support`。
-- Agent 会话指标、趋势和原始会话下钻：使用 `agent-analytics`。

package/skills/solvea-desk/references/report/fields.md

@@ -1,82 +0,0 @@
-# Shulex Desk Fields
-
-`datasource.xlsx` 默认读取 `data` sheet。接口字段使用驼峰命名，字段含义以本文件为准；不要要求或生成运行态 `schema.md`。本文件面向 Agent 做报表分析，只描述 `datasource.xlsx` 里可见字段、单位、口径和限制，不描述后端数据库表结构。
-
-## 数据粒度与默认口径
-
-- `data` sheet 一行代表一个工单，时间范围按工单创建时间筛选。
-- 顶层字段可直接按 Excel 列读取和聚合；`messages` 是每个工单内的消息明细数组，需要先解析 JSON 字符串再展开统计。
-- 时间字段由接口返回为时间值；分析时按用户要求的业务时区展示，默认使用北京时间。
-- `replyTime`、`responder`、`isAiReply` 描述当前工单的最新有效对客回复。
-- `firstReplyTime`、`firstReplyDuration` 描述当前工单的首次有效对客回复。
-- `replyDuration` 单位是分钟，`resolutionDuration` 单位是小时。
-- 广告、通知、AI 关单是否剔除取决于用户口径；默认报表需要说明是否使用了这些过滤条件。
-
-## 顶层字段
-
-| 模块 | 接口字段 | 中文字段 | 字段说明 | 必需性 | 用途 | 备注 |
-|------|----------|----------|----------|--------|------|------|
-| 工单标识 | `ticketId` | 工单ID | 工单唯一 ID，用于关联消息明细、回复明细和标签。 | 必需 | 工单去重、明细定位、关联导出 | 系统内部 ID；不要展示给业务用户作为唯一可读编号。 |
-| 工单标识 | `ticketNumber` | 工单编号 | 对外展示的工单编号，便于客服和运营人员查询工单。 | 必需 | 页面展示、人工核对、导出识别 | 面向用户展示时优先使用该字段。 |
-| 工单基础 | `ticketTitle` | 工单标题 | 工单展示标题；通常来自客户第一条消息主题或系统维护后的标题。 | 建议 | 明细展示、问题排查 | 不作为核心聚合字段。 |
-| 工单基础 | `ticketStatus` | 工单状态 | 工单当前所处的处理状态。 | 必需 | 按 Processing / Open / Pending / Solved 等筛选 | 枚举以接口返回值为准，例如 `open` / `pending` / `solved` / `ai_handing`。 |
-| 工单基础 | `channel` | 工单来源渠道 | 工单来源渠道，例如站内信、Email、livechat。 | 必需 | 按 Email / Livechat / Buyer Msg / Amazon / Shopify 等筛选、分组 | 渠道展示值以接口返回为准。 |
-| 业务维度 | `store` | 店铺 | 客户咨询所关联的店铺。 | 必需 | 按店铺筛选、分组统计 | 为空时说明该工单没有可用店铺信息。 |
-| 业务维度 | `brand` | 品牌 | 客户咨询所关联的品牌。 | 必需 | 按品牌筛选、分组统计 | 为空时不要按字段名猜测品牌。 |
-| 业务维度 | `category` | 品类 | 客户咨询涉及的产品品类。 | 必需 | 按品类筛选、分组统计 | 为空时说明当前快照没有品类信息。 |
-| 业务维度 | `tags` | 标签 | 当前工单已绑定且生效的标签列表。 | 必需 | 按标签筛选、做问题类型分析 | 可能是数组或 JSON 字符串；需要按多标签展开时先解析。 |
-| 业务维度 | `platform` | 平台 | 客户咨询来源的平台，例如 Amazon、Shopify、eBay 等。 | 建议 | 按平台筛选、分组统计 | 为空时不等同于未知渠道。 |
-| 业务维度 | `site` | 站点 | 客户咨询来源的国家、地区或站点。 | 建议 | 按 US / CA 等站点筛选、分组 | 接口可能已做站点/国家/地区回退。 |
-| 人员维度 | `currentAssignee` | 当前负责人 | 当前负责处理该工单的客服。 | 必需 | 按当前客服筛选、看待处理归属 | 未分配工单返回空。 |
-| 人员维度 | `resolver` | 解决人 | 最后将工单标记为已解决的人；如果由 AI 解决，则显示为 Solvea-AI。 | 必需 | 统计客服解决量、区分 AI/人工解决 | AI 关单时不要当成人工解决量。 |
-| 人员维度 | `responder` | 回复人 | 最新有效对客回复的回复人；如果是 AI 回复，则显示为 Solvea-AI。 | 必需 | 统计回复量、平均响应时长、首响表现 | 只代表最新有效对客回复，不代表全量回复人。 |
-| 人员维度 | `assigneeGroup` | 客服组/团队 | 该工单当前分配人归属的客服团队；优先使用工单团队，缺失时用负责人部门兜底。 | 建议 | 按团队/客服组统计绩效 | 不依赖姓名拆分。 |
-| 客户维度 | `customerId` | 客户ID | 客户在系统中的唯一标识。 | 建议 | 客户去重、客户维度统计 | 仅适合内部关联，不建议直接对外展示。 |
-| 客户维度 | `customerContact` | 客户邮箱/联系方式 | 客户邮箱或其他联系方式。 | 建议 | 关联同一客户、客户维度筛选 | 可能为空；不要在报表中泄露不必要的隐私信息。 |
-| 时间字段 | `ticketCreatedAt` | 工单创建时间 | 工单在系统中创建的时间。 | 必需 | 新增工单量、按创建时间筛选、趋势统计 | `fetch_sources.py` 的时间窗按该字段筛选。 |
-| 时间字段 | `customerMessageTime` | 客户来信时间 | 当前工单最早客户消息时间。 | 必需 | 消息量统计、响应时长起点 | 为空时首响/响应相关指标需要说明限制。 |
-| 时间字段 | `firstReplyTime` | 首次回复时间 | 客户来信之后，客服或 AI 第一次有效对客回复时间。 | 必需 | 计算首响时长 | 只统计有效对客回复。 |
-| 时间字段 | `replyTime` | 回复时间 | 最新有效对客回复发出的时间。 | 必需 | 回复趋势、响应表现 | 只代表最新有效对客回复时间。 |
-| 时间字段 | `resolvedAt` | 解决时间 | 工单被标记为已解决的时间。 | 必需 | 已解决工单、解决率、解决趋势 | solved 工单缺少解决时间时返回空，解决率口径需说明。 |
-| 时间字段 | `transferToAgentTime` | 转人工时间 | 工单从 AI 或自动流程转交给人工客服处理的时间。 | 必需 | AI 转人工后人工响应表现 | Human-in-loop 相关分析字段。 |
-| 指标计算 | `replyDuration` | 回复时长 | 客户来信到最新有效对客回复之间的耗时。 | 必需 | 平均响应时长、超时回复 | 单位：分钟；连续来信/连续回复的细节由接口口径处理。 |
-| 指标计算 | `firstReplyDuration` | 首响时长 | 客户来信到第一次有效对客回复之间的耗时。 | 必需 | 平均首次响应时长 | 单位：分钟；工单先转人工时，接口可能按转人工后人工首响口径计算。 |
-| 指标计算 | `resolutionDuration` | 解决时长 | 工单从创建或转人工起点到解决之间的耗时。 | 必需 | 平均解决时长 | 单位：小时；解决时间缺失或时间倒挂会影响该值。 |
-| 指标计算 | `isFirstReply` | 是否首次回复 | 标识当前工单是否已有首次有效对客回复。 | 必需 | 区分有无首响、首响覆盖率 | 返回 true/false。 |
-| AI/口径 | `isAiReply` | 是否AI回复 | 标识最新有效对客回复是否由 AI 发出。 | 必需 | 区分 AI 回复和人工回复 | 只代表最新有效对客回复，不代表工单历史上是否曾有 AI 回复。 |
-| AI/口径 | `isAiResolved` | 是否AI解决/AI关单 | 标识该工单是否由 AI 标记为已解决或关闭。 | 必需 | 支持排除 AI 关单、只看人工解决 | 统计人工解决量时需要排除。 |
-| AI/口径 | `isAdvertising` | 是否广告工单 | 标识该工单是否被判定为广告或垃圾工单。 | 必需 | 默认报表口径剔除广告 | 是否剔除必须在口径说明里写清楚。 |
-| AI/口径 | `isNotification` | 是否通知工单 | 标识该工单是否为通知类工单。 | 必需 | 默认报表口径剔除通知 | 是否剔除必须在口径说明里写清楚。 |
-| 满意度 | `satisfactionScore` | 满意度分数 | 客户提交的满意度评分，取值 1-5，分数越高越满意。 | 可选 | 满意度（CSAT）统计、按评分分档、差评筛选 | 仅客户回收满意度调查后才有值；未发送或未回收时为空，空值不要按 0 计入均值或差评。 |
-| 满意度 | `satisfactionFeedback` | 满意度反馈 | 客户提交满意度时填写的文字反馈。 | 可选 | 差评归因、客户原声摘录、好评/差评文本分析 | 多数工单为空，且只有提交了 `satisfactionScore` 才可能有；含主观/隐私信息，展示需注意脱敏。 |
-| 消息维度 | `messages` | 消息明细 | 工单内客户消息、客服回复、AI 回复和系统消息的明细数组。 | 建议 | 展开对话、做消息趋势、响应时长、时段分析 | 在 `datasource.xlsx` 中通常是 JSON 字符串；分析前先解析。 |
-
-## `messages[]` 子字段
-
-`messages` 字段是一组消息明细。需要按消息粒度统计时，先对每行的 `messages` 做 JSON 解析，再把数组展开成消息明细表。
-
-| 模块 | 接口字段 | 中文字段 | 字段说明 | 必需性 | 用途 | 备注 |
-|------|----------|----------|----------|--------|------|------|
-| 消息维度 | `ticketId` | 工单ID | 这条消息所属工单 ID。 | 必需 | 展开后回连工单维度 | 与顶层 `ticketId` 一致。 |
-| 消息维度 | `messageId` | 消息ID | 消息或回复的唯一 ID。 | 必需 | 消息去重、明细定位 | 只在消息明细粒度使用。 |
-| 消息维度 | `messageTime` | 每条消息时间 | 每条消息实际发生的时间。 | 必需 | 消息趋势、响应时长、时段分析 | messages 数组内每条消息都有 `messageTime`。 |
-| 消息维度 | `messageType` | 消息类型 | 标识消息属于客户消息、人工回复、AI 回复或系统消息等具体类型。 | 必需 | 区分客户消息、客服回复、AI 回复、系统消息 | 展示值以接口返回为准。 |
-| 消息维度 | `senderType` | 发送方类型 | 标识消息由谁发出。 | 必需 | 区分客户、客服、AI、系统消息 | 常见值：`customer` / `agent` / `ai` / `system`。 |
-| 消息维度 | `isAiReply` | 是否AI回复 | 标识该条消息是否 AI 回复。 | 必需 | 按消息粒度统计 AI 回复 | 与顶层 `isAiReply` 不同；这里描述单条消息。 |
-
-## 可直接计算的常见指标（建议口径）
-
-以下指标是基于当前接口字段可直接计算的默认分析建议，不是业务官方固定口径。用户指定口径优先；用户改口径时，应基于同一份快照重算并在 `calculation_notes.json` 里说明过滤条件、分子分母和限制。
-
-| 指标 | 默认算法 | 关键字段 | 口径提醒 |
-|------|----------|----------|----------|
-| 工单量 | 去重统计 `ticketId` | `ticketId` | 当前快照按工单创建时间筛选。 |
-| 新增趋势 | 按 `ticketCreatedAt` 日期分组统计工单量 | `ticketCreatedAt` | 输出时说明时区。 |
-| 解决率 | 已解决工单数 / 工单总数 | `ticketStatus`, `resolvedAt` | 是否只算统计范围内解决、是否剔除 AI 关单，要写清楚。 |
-| 平均首响时长 | `firstReplyDuration` 的平均值 | `firstReplyDuration` | 单位分钟；空值不应按 0 计算。 |
-| 平均回复时长 | `replyDuration` 的平均值 | `replyDuration` | 单位分钟；空值不应按 0 计算。 |
-| 平均解决时长 | `resolutionDuration` 的平均值 | `resolutionDuration` | 单位小时；解决时间缺失会影响样本。 |
-| AI 回复占比 | `isAiReply=true` 的工单数 / 有有效回复的工单数 | `isAiReply`, `replyTime` | 顶层口径按最新有效回复；历史消息维度需展开 `messages`。 |
-| AI 解决占比 | `isAiResolved=true` 的工单数 / 已解决工单数 | `isAiResolved`, `ticketStatus` | 分母需说明是否只含已解决工单。 |
-| 转人工量 | `transferToAgentTime` 非空的工单数 | `transferToAgentTime` | 仅代表已有转人工时间的工单。 |
-| 平均满意度 | `satisfactionScore` 的平均值 | `satisfactionScore` | 分母只算有满意度评分的工单，空值不计入；需说明满意度回收率（有评分工单 / 工单总数）以免被低样本误导。 |

package/skills/solvea-desk/references/report/report-design.md

@@ -1,200 +0,0 @@
-# Shulex Desk HTML Design
-
-This document defines the visual and structural standard for `solvea-desk` HTML deliverables.
-The renderer uses the sibling files:
-
-- `report.css`: fixed self-contained CSS for the report.
-- `report-template.html`: fixed semantic HTML shell with renderer placeholders.
-
-Agents should not copy these files into `analysis.py`. Generate structured `report_data.json`, then call `scripts/report/render_report.py` to build the HTML.
-
-## Design Read
-
-This is an operational report for support leads and business operators. It should feel calm, precise, and audit-friendly: closer to a finance packet or executive operations memo than a marketing page.
-
-Use the taste/frontend principles only selectively: readable hierarchy, restrained palette, stable density, and no generic AI decoration. This is not a landing page, portfolio, or brand hero.
-
-Design goals:
-
-- Make the first screen useful: show report title, time range, data freshness, and 3-5 key metrics.
-- Make numbers easy to audit: every KPI must have a nearby short basis/definition.
-- Make dense tables readable without looking like raw exports.
-- Use a restrained palette and stable layout that prints cleanly.
-- Keep the report self-contained: no remote fonts, no external CSS, no external JavaScript.
-
-Avoid:
-
-- Hero/landing-page composition, decorative gradients, glassmorphism, large empty visual sections.
-- Nested cards and card-heavy dashboards.
-- Emoji, playful copy, marketing taglines.
-- Low-contrast grey text, tiny table text, or saturated single-hue themes.
-
-## Report Data Contract
-
-`analysis.py` writes `STATE_TASK_DIR/report_data.json`. The renderer accepts this shape:
-
-```json
-{
-  "report_slug": "assignee_group_weekly",
-  "title": "客服组周报",
-  "subtitle": "按客服组统计本周工单量、状态分布和 AI 解决情况。",
-  "range": "2026-06-01 至 2026-06-08（北京时间）",
-  "row_count": 55,
-  "truncated": false,
-  "generated_at": "2026-06-08T10:30:00+08:00",
-  "kpis": [
-    {"label": "工单总量", "value": "55", "basis": "按工单 ID 去重"}
-  ],
-  "sections": [
-    {
-      "title": "客服组工单量",
-      "description": "按当前处理组汇总。",
-      "chart": {
-        "chartType": "bar",
-        "xKey": "group",
-        "yKey": "tickets",
-        "label": "工单数"
-      },
-      "columns": [
-        {"key": "group", "label": "客服组"},
-        {"key": "tickets", "label": "工单数", "numeric": true}
-      ],
-      "rows": [
-        {"group": "CxjOnly", "tickets": 23}
-      ],
-      "note": "未设置客服组的工单归入未分组。"
-    }
-  ],
-  "footer": "本报告由 Shulex 基于当前账号授权范围内的工单快照生成，仅供运营分析使用。"
-}
-```
-
-Rules:
-
-- `report_slug` must be ASCII lowercase snake_case, for example `weekly_ticket_summary`.
-- `report_data.json` must contain top-level `kpis` or `sections`; usually both. The renderer rejects free-form legacy shapes that only contain `overview`, `personal_performance`, `daily_trend`, or `status_distribution`.
-- `row_count` means the raw snapshot row count from `fetch_sources.py`; `render_report.py` fills it from `manifest.json.row_counts` when omitted. Do not use filtered analysis sample size here.
-- Visible labels should be Chinese business labels. Raw field names can appear only in short audit notes when necessary.
-- Table columns should be ordered by business importance, not raw data order.
-- Use `numeric: true` for numeric columns so the renderer can right-align and use tabular numbers.
-- `sections[].chart` is optional. HTML reports support self-contained static `bar`、`line`、`pie`、`scatter` charts. Use the same chart type vocabulary as the `render_chart` tool.
-- `bar`、`line`、`scatter` charts use `{"chartType": "bar|line|scatter", "xKey": "...", "yKey": "...", "label": "..."}`.
-- `pie` charts use `{"chartType": "pie", "nameKey": "...", "valueKey": "...", "label": "..."}`. `xKey/yKey` can be used only when they clearly mean category/value.
-- `chart_type` and `type` are accepted as aliases, but new `analysis.py` should write `chartType`.
-- Chart sections always render a toggle: table is selected first, and the same `rows` can be viewed as the configured static chart.
-- Agents must not generate chart HTML, CSS, JavaScript, or full ECharts options for HTML reports. The renderer builds the static chart from the same summary `rows`, so token cost stays close to a table plus a small chart config.
-- Keep `sections[].rows` to report-sized summaries. Long raw detail belongs in `<report_slug>_detail.xlsx`.
-- Do not put raw HTML in `report_data.json`; the renderer escapes values intentionally.
-
-## Analysis Script Contract Template
-
-`analysis.py` should define small local helpers before building `report_data`. This avoids the common failure where `columns` is written as `["日期", "工单数"]` instead of renderer-readable objects.
-
-Copy this shape and fill it with the current report's metrics and summary rows:
-
-```python
-REPORT_SLUG = "weekly_ticket_summary"
-
-
-def kpi(label, value, basis):
-    return {"label": label, "value": str(value), "basis": basis}
-
-
-def col(key, label, numeric=False):
-    item = {"key": key, "label": label}
-    if numeric:
-        item["numeric"] = True
-    return item
-
-
-def section(title, columns, rows, chart=None, description="", note=""):
-    return {
-        "title": title,
-        "description": description,
-        "columns": columns,
-        "rows": rows,
-        **({"chart": chart} if chart else {}),
-        **({"note": note} if note else {}),
-    }
-
-
-daily_rows = [
-    {"date": "03-01", "tickets": 12},
-    {"date": "03-02", "tickets": 18},
-]
-
-report_data = {
-    "report_slug": REPORT_SLUG,
-    "title": "工单周报",
-    "range": "2026-03-01 至 2026-03-07（北京时间）",
-    "truncated": bool(manifest.get("truncated")),
-    "kpis": [
-        kpi("工单总量", total_tickets, "按工单 ID 去重"),
-    ],
-    "sections": [
-        section(
-            "每日工单趋势",
-            [col("date", "日期"), col("tickets", "工单数", numeric=True)],
-            daily_rows,
-            chart={"chartType": "line", "xKey": "date", "yKey": "tickets", "label": "工单数"},
-        )
-    ],
-}
-```
-
-Rules for the template:
-
-- `columns` 必须是对象数组，每个对象至少有 `key` 和 `label`；不要写成字符串数组。
-- Every `rows` item must use the same keys declared in `columns`.
-- Chart data comes from the same `rows`; do not create separate `x` / `series` fields for HTML.
-- Run `render_report.py --validate-only` immediately after writing `report_data.json`.
-
-## Page Structure
-
-The renderer outputs this structure:
-
-1. Report masthead
-   - Title
-   - Subtitle
-   - Meta strip: data range, row count, truncation status, generated time
-2. KPI band
-   - 3-5 compact KPI blocks
-   - Each block has label, value, and one short basis line
-3. Main sections
-   - Each section starts with an `h2`
-   - Optional static chart for compact trends or breakdowns; chart sections include a table/chart toggle by default
-   - Tables for comparisons and breakdowns when no chart is configured
-   - Short notes below tables for caveats
-4. Calculation notes
-   - Compact formula / range / definition from `calculation_notes.json`
-5. Footer
-   - Authorized snapshot statement and limitations
-
-## Rendering
-
-Use the renderer:
-
-```bash
-npx --yes @shulex/cxclawctl@latest script skills/solvea-desk/scripts/report/render_report.py \
-  --task-id "<task_id>" \
-  --report-slug "assignee_group_weekly"
-```
-
-Default paths:
-
-- Input: `workspace/state/solvea-desk/<task_id>/report_data.json`
-- Input: `workspace/state/solvea-desk/<task_id>/calculation_notes.json`
-- Output: `workspace/outputs/solvea-desk/<task_id>/<report_slug>.html`
-
-Use `--report-data`, `--notes`, or `--output` only for local debugging or unusual internal workflows.
-
-## File Naming
-
-The report file name must match the analysis scenario:
-
-- Weekly summary: `weekly_ticket_summary.html`
-- Assignee group breakdown: `assignee_group_weekly.html`
-- Channel trend: `channel_trend.html`
-- CSAT analysis: `csat_analysis.html`
-
-When the user refines the same report, overwrite the same file. When the user starts a clearly different report, choose a new slug.

package/skills/solvea-desk/references/report/report-template.html

@@ -1,44 +0,0 @@
-<!DOCTYPE html>
-<html lang="zh-CN">
-<head>
-  <meta charset="UTF-8">
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  <title>{{REPORT_TITLE}}</title>
-  <style>
-{{REPORT_CSS}}
-  </style>
-</head>
-<body>
-  <main class="report">
-    <article class="sheet">
-      <header class="masthead">
-        <p class="eyebrow">Shulex Desk</p>
-        <h1>{{REPORT_TITLE}}</h1>
-        <p class="subtitle">{{REPORT_SUBTITLE}}</p>
-        <div class="meta-strip">
-{{META_ITEMS}}
-        </div>
-      </header>
-
-      <section class="section">
-        <div class="kpi-grid">
-{{KPI_BLOCKS}}
-        </div>
-      </section>
-
-{{SECTIONS}}
-
-      <section class="section">
-        <h2>口径说明</h2>
-        <div class="formula-list">
-{{FORMULA_NOTES}}
-        </div>
-      </section>
-
-      <footer class="footer">
-{{FOOTER}}
-      </footer>
-    </article>
-  </main>
-</body>
-</html>