# Workspace 输出与兴趣数据

## 权威位置

活跃的 DSH Workspace 是用户数据唯一的正式目的地。插件从宿主 Workspace 注册表解析它，
并在该根目录下写入相对路径，包括：

- `input/resumes/`：用户提供的简历副本；
- `profile/`：已确认的求职画像；
- `data/`：岗位和兴趣台账；
- `reports/`：生成的报告；
- `assets/`：生成的网站资源；
- `config/`：项目配置。

插件不会回退到固定盘符、仓库目录或当前工作目录。如果无法解析活跃 Workspace，
就不会写入用户数据。

## 求职画像驱动的网站菜单

`job_hunting_build_site` 读取已确认画像中的意向城市和行业，把它们作为网站的展示范围：
前期对话确认了哪些城市，城市菜单就只展示哪些城市；未确认城市时才按岗位数据生成菜单。
这不是替用户改写画像的分类筛选器，而是把协商结果映射成页面菜单和内容范围，页面仍可在已展示
的菜单项之间切换。

行业分类默认在不同城市之间共享。只有用户明确要求各城市使用不同分类时，画像才写入
`shareIndustriesAcrossCities: false` 和 `industriesByCity`，网站再按当前城市展示对应分类。
用户提出非标准行业名时，系统可以给出建议映射，但不会自动改写；最终展示以用户确认的分类为准。

## 浏览器临时状态与正式兴趣状态

静态网站使用浏览器 `localStorage` 保存用户浏览岗位时的临时、本地标记。这些标记不是正式
记录。用户需要先导出 JSON，再明确同步到 Workspace 兴趣台账。Workspace 台账是报告和
意向岗位池的正式权威来源。

## 静态网站与提醒

网站在构建阶段内嵌数据，可以通过 `file://` 打开，不会在运行时请求旁边的 JSON 文件。
插件配置中的 `schedule.enabled` 默认是 `false`，不能替代宿主的 DSH 原生 Schedule。原生
Schedule 必须通过独立的 `dsh-schedule.cordis.yml` overlay 在启动时显式启用，并且只对当前
DSH 会话有效；它到时间提醒用户，不保证 Windows 后台运行，也不会作为无人值守爬虫运行。

提醒本身不会写入岗位数据或授权浏览器采集。到期后仍需用户确认本轮白名单 URL 和只读范围，
再调用 `job_hunting_collect_browser_jobs`；采集成功后才生成当天报告。岗位、画像和报告仍然
只写入本节前文所述的活跃 Workspace。

## 经批准的 Windows 快捷方式

v0.1 提供一个可由已批准的宿主或手工集成调用的模块级 Windows 快捷方式服务。它要求明确的
用户批准，目标必须是经过校验的 `index.html`，会写入归属 Manifest，并拒绝覆盖无归属的
同名快捷方式。它不会自动创建快捷方式；如果宿主没有集成该模块，则暂不提供快捷方式
用户入口尚未提供。详见发布清单中的批准和重复更新检查。