沿着石墙，抬头看树。
查看画廊与说明用途与结果
最快了解这个项目
为什么需要它
媒体最容易同时出现三种问题：想用时找不到；好照片淹没在分类目录里；换机或手机故障后只剩零散副本。把所有东西复制到第二套库、持续后台同步或自动上传又会制造更多状态。这个项目选择一个可重建目录、职责清楚的既有模块和逐次有界处理；同时把文件管理器中的原件现状当作本人决定，而不是让旧索引或恢复包反过来支配原件。
举个实际例子
我说：把手机里的新照片安全拿出来，我要尽快拔线。先与已有材料和媒体核对重复，补齐并验证两盘副本，精确清空后告知可拔；电脑继续筛选分类并展示这批最终留下的内容。恢复差异准备好后再连手机回写，不用等云端上传才能拔线。
最后我会得到什么
查找时得到少量仍能打开的照片、视频或录音及匹配理由；整理时得到本批保留、分类或相册结果。手机恢复包、真正写回手机和云端对象各自报告。现有目录和云端映射有已记录的数量与日期，但本页没有把本地“已同步”当成今天远端播放、手机回写或从零恢复成功。
成功时
查找交回现存原件；整理、手机双盘保全、恢复包和获准云端同步按各自完成步骤报告，实际手机回写另行核对。
发现问题时
重复关系、画面意义、地点或恢复责任说不清时，只把少量争议对象留给人判断，不重做整个媒体库。
入口不可用时
原件目录、手机或备份盘暂不可用时，只暂停受影响步骤，保留已经核对的副本与精确缺口；查询不会顺手上传或清空手机。
从哪里开始
直接告诉 AI 想找哪张照片、哪段录音，或说明要处理一批本地、手机或云端媒体；实际保全和同步使用项目已有入口。
需要准备什么
- 记得的地点、时间、画面或录音话语
- 整理时要处理的文件和保留选择
- 手机或云端工作的目标设备与期望范围（扩大授权时才另行确认）
从开始到拿到结果
- 1AI选对应的媒体路线
按这次目的进入查找、单文件接入或手机/云端处理。单纯查找只用已有目录，不把找到候选误说成分类、保全或恢复已经完成。
- 2核对原件与去留
搜索返回现存文件；新增先看能否打开、画面意义、质量和重复关系。不确定的先留着，用户已删除的原件不从旧索引复活。
- 3分阶段完成保全与恢复
手机新文件先验证电脑两盘副本，再精确清理并说明能否拔线；电脑离线分类后准备恢复差异。手机写回与云端对象、播放分别回读。
- 4交付可用结果和缺口
返回原件或本批最终保留内容，分别说明目录、恢复包、云端和手机的真实状态。设备不可用时留下已完成部分及继续入口。
从这些需求了解功能
从一个实际问题看它怎样处理、交回什么；当前能做到哪一步和仍有哪些限制，也写在对应说明中。
10 张实拍照片
旅行中留下的画面
七座城市，十张实拍。保留横竖构图，单击查看高清大图。打开后可缩放、滚动查看细节，也可关闭或切换上一张、下一张。
项目指标与相关入口查看规模、覆盖范围和关联能力
当前项目指标
- 照片
- 3,485张
- 视频
- 116 个
- 音频
- 754录音 + 3音乐/铃声
- 云端登记
- 4,358项已映射 · 当前播放另验
个人媒体怎样从线索走到结果 · 6 步
找到真实原件，判断留下什么，再分别完成保全和恢复
找回一张照片、整理一批新增、保全手机和同步云端是不同任务。它们围绕同一批真实文件工作，但各自交付可核对的结果。
- 已给出的线索缩小到相关的照片、视频或录音
按记得的地点、描述、类别或时间查找；拍摄地点和画面上写着的地名分开看。
- 现存原件交回少量可打开的候选
先核对文件仍在。需要一起看时才做临时浏览入口，结束后清理入口，不动原件。
- 单个本地新增只接入已经看过的一份文件
确认内容、类别和时间，再放入照片、视频或音频的正式位置并核对另一盘副本。同一视频的不同封装先证明等价，避免当新视频重复收藏。
- 视觉整理决定保留、类别和近重复
把少量图片一起看，比较画面意义、质量和更完整版本；看不清或取舍不明就保留待复核。
- 手机新文件先保全，再精确清理
把本次新共享文件逐项存到电脑两块盘并读回核对；只清理已核准的手机文件，确认可拔后再在电脑上慢慢整理。
- 各自的恢复目标手机和云端分别确认
电脑准备手机恢复内容，第二次连接才实际写回；云端按既有授权另行同步并核对对象、相册和播放状态。
用户说明
目的和必要选择- 想找的内容或要整理的这一批文件
- 近重复、意义不明时的最终取舍
- 超出现有授权的云端范围或外部删除决定
项目处理
原件、判断与恢复- 从照片、视频和录音的现存原件找回结果
- 看画面和重复关系，把确定保留的文件放回正确位置
- 双盘保全手机新文件，并分别核对手机恢复与云端结果
停下的边界
避免猜测与误删- 不因文件名猜人，也不把不确定的近重复直接删除
- 查询不自动上传；清理手机只针对本次已保全的具体文件
- 手机无法读取或远端状态未知时报告缺口，不声称已恢复
它负责
- 按地点、日期、画面文字、描述或录音话语找回仍存在的照片、视频和录音。
- 把本人愿意常看的照片放进精选；普通视频留在视频目录，不因未入精选删除本人已留下的内容。
- 需要一起浏览时建立临时入口，用完只移除这个入口，不复制或删除原件。
- 把一份已复核的本地媒体接入正式位置和备份；同内容视频变体先核实关系，避免重复收藏。
- 判断新增媒体能否打开、画面讲什么、质量如何、是否有更完整或高度相似的版本。
- 照片、视频和音频各留在自己的原件位置；移动和改名后仍能从同一目录找回。
- 手机共享范围里的新文件，无论是照片、文档还是未知格式，先核对两盘副本；非媒体随后交给对应项目。
- 维护有容量边界的手机照片视频恢复包，并在已有授权内分别核对云端对象、相册关系与播放状态。
它不负责
- Word、PDF 和压缩包等手机文件会先防丢保全，但不作为照片或录音加入媒体目录；之后交给材料或所属业务。
- 不全库认人或建立人物画像；只有少量选定原图确需判断本人时才走独立能力。
- 查找和本地整理不自动上传；云候选、本地状态和真正的云端结果分别报告。
- 不清理手机联系人、聊天、账号、应用私有或系统数据，也不递归删目录或恢复出厂设置。
- 缩略图、缓存和中间文件不会被当成值得保留的原件。
- 不为一批新媒体建立另一套常驻服务、任务队列或第二份媒体库。
产品思想与设计核心
原件只有自己的正式位置
照片、视频和音频仍各在原来的文件目录。查找用的目录只记住怎样找到它们，不另复制一套相册。
精选是选择，不是额外副本
值得常看的照片可以进精选，没有数量配额；普通视频留在视频目录，本人手筛留下的内容不会因精选标准再被删除。
本人删掉的原件不会被旧副本复活
文件管理器中的真实原件现状是准绳。后续维护让查找、备份和手机包跟随当前文件；下次连手机时，也先分清本人删除、移动、改名和 AI 曾清空。拿不准就保留。
看懂画面与读出文字各有来源
画面里的场景和价值靠视觉判断，图片上的字靠文字识别；两类证据一起帮助找回原件，不建立第二个文字媒体库。
公开内容按实际敏感性逐项判断
普通照片不会因来自个人媒体库就整类排除；私人正文和秘密值仍逐项保护，技术层保留现行公开分级。
本地新增一次处理一份已复核文件
先确认文件和说明，再实际接入；同一视频的不同容器形式要另证内容等价，不从任意目录自行扩张来源。
录音移动不等于重新识别
录音和音乐留在各自现行目录，搬动已知文件时沿原内容身份找回已有转写和云端关系，不为改名重新跑识别或上传。
手机分两次连接处理
第一次先存稳新文件并精确清理，确认可拔后在电脑上分类和准备差异；第二次连接才按手机真实现状写回。云端上传不决定何时拔线。
分类要说出内容意义
移动到目录不是判断完成；画面意义、质量和近重复关系说不清时保留待复核。
每种结果都要单独收口
本地目录、备份、手机恢复包、真正写回手机和云端同步分别核对。有依据的本人认识或文件定位交给对应项目，不把一次导入说成全部个人更新完成。
数据安全、清空和回写各是一步
两盘副本读回后才有可恢复字节；本次精确清空收稳后才告知第一阶段可拔。离线准备和第二次回写不会由保全自动完成。
云端动作只跟随实际授权
照片留在本地、随手机携带和放到云端是三个选择。既有范围内的正常增量不用每批重复批准；扩大账号或来源另行确认。
小批量工作保持轻量
一次普通整理尽量快速完成，不为它新建服务或扫描全库；既有小批量速度目标和实际缺口留在技术依据中。
相册把选中的照片组织在一起
一个具名相册只保存选择关系，不复制照片或改掉原分类；用户确认的地点保留来源，保存相册关系也不自动上传。
项目怎样演化到现在
先解决想用时找不到
照片、视频和录音共用一个可重建目录，按线索返回真实原件，临时浏览不建立另一份原件库。
阶段依据
- 2026-08-23—08-24 · 形成照片、视频与音频统一查找和临时浏览。 原记录的依据标签为“milestone-01”，未附Git提交编号。
手机先安全取出，再慢慢整理
增加两盘保全、重复核对和精确清理，分出可拔线节点；电脑继续分类，需要时再生成手机恢复差异。本人删除和整盘不可用始终区别处理。
阶段依据
- 2026-08-25 · 手机新增文件先完成两盘保全，再明确可拔线节点。 原记录的依据标签为“milestone-02”，未附Git提交编号。
- 2026-08-26—08-27 · 分类、近重复治理和恢复包范围分开，目录可重建。 原记录的依据标签为“milestone-03”，未附Git提交编号。
- 2026-08-30 · 当时云端只生成未上传候选；该历史边界不能代替后续已获准的同步能力。 原记录的依据标签为“milestone-04”，未附Git提交编号。
查找、筛选与云端保全分开协作
录音可定位已有转写片段，图片按画面和必要OCR（光学字符识别）文字检索，精选入口不设配额；云端从本地候选发展到获准同步，实际对象、播放就绪、手机包与手机回写分别验收。
阶段依据
- 2026-09-02—09-14 · 录音片段定位、六类图片入口、音频归位与手机三阶段形成；首轮云对象已有回读，实际播放与手机回写仍分别验收。
ba43b4c9fdef18a51e8165944fe807e7b76bd43c
选定照片可以组织成相册
具名相册保存选择关系，不复制第二份原件或改掉原分类；新媒体与其他个人项目之间只回写各自负责的认识和结果，不建立中央资料副本。
阶段依据
- 2026-09-15–09-18 · 选定照片可以组织成相册
22a6109
完整项目状态与证据边界
已确认事实
- 当前本地目录4358条，仍由照片、视频和音频原件根分别保存。新增具名照片相册是可重建的选择关系，不改变原件分类、不另存第二份图片库；相册用于手机恢复组织与云端关系计划，实际写回和上传另行执行。
- 9月22日已回读PRIVATE（私有） main 22a6109b7ef787a98d97069884d3e5166316b09a；本次增量仅为AGENTS.md与USER_REQUIREMENTS.md的个人更新协作合同。相册和目录仍沿09e8efb、ba43b4c及9月18日已核对材料，未新建采集器或重跑私人媒体流程。
- 2026-09-18只读目录4358条：3485照片、116视频、757音频，其中754录音和3项音乐/铃声，后两类各自数量仍Unknown（未验证）。SQLite quick_check=ok及根可达，只证明目录状态和来源可见，不证明所有原件逐一存在或重新哈希。
- 当前照片精选910项，位于E:\Pictures\精选；普通视频在E:\Videos根，特殊视频独立一层，不设视频精选目录。精选无数量配额，用户手筛保留件不因不够精选再次删除。
- 截图细项保留 2026-09-02 观察：15,823 张中，6,440 张带 OCR（光学字符识别） 证据，4,287 张有 visible_text；这不是本轮新增截图覆盖率。当前检索已把确认的处理链/旧路径/哈希移回 provenance（来源说明），真实技术文字与不确定文本保留，避免内部痕迹污染内容召回。
- 本地 keeper（保留原件）、Google Photos 云候选和手机携带/恢复资格分别审查。普通新增不会自动进入手机包；严格精选沿用既有资格，普通内容须明确 phone-recovery 及理由。某一批没有合格精选或手机增量为0都是正常结果。
- 电脑端手机包2245项、43,010,158,632字节已由来源Owner于9月13日核对G实物；本页未取得手机Owner最新回写回执。电脑包可用、手机精确清空和实际回写分别验收，不从历史误增清单推定当前待办。
- 电脑、手机携带和云端恢复用途分别选择；普通新增keeper不自动进入手机包。原文已明确退出的内容随有效集合收敛，未知资格不猜成无价值，也不因旧计划差额自动补入。
- 选定录音后，locate-audio 复核原音 SHA-256，复用 ChineseASR 已保留的时间段，返回原音起点下的起止时间、逐词覆盖和有限片段；查询不播放、不启动模型、不写库。缺时间时只给单件本地 ASR（自动语音识别） 接续，视频内部定位仍未提供。
- 当前2245项、43,010,158,632字节（43.01十进制GB），低于60GB；云恢复集照片视频2382项/74.47GB，连音频3139项/94.60GB，完整云保留集4230项/96.18GB。云恢复集是云对象的分类集合，不是重复上传一份ZIP。
- 来源Owner于9月13日23:21Z完成最终全量零写回读：Photos3357图片+116视频共76,049,921,114字节，Drive754录音+3音乐/铃声共20,129,267,708字节；合计4230项、96,179,188,822字节。Photos已登记ID均可读、9相册关系一致；Drive完整分页核对ID/SHA-256/大小/父目录一致。
- 查询直接使用 SQLite 条件/FTS，返回逐词命中字段、有限片段与范围；当前 source 明确取消 750/250 ms 硬门，不为几秒级耗时牺牲 AI 所需含义和证据。旧精确查询 239 ms 仅是历史观测，不是当前验收阈值。
- personal_media.py 与 phone_file_preserve_clear.py 为两个主入口；目录/云状态共用一份SQLite。视频播放处理的有界复查复用PCConfig可见、可停止的任务窗口，不另建媒体服务、计划任务或第二数据库。
- PRIVATE（私有） wlyaaaaa/personal-media，默认main；本轮已发布源码22a6109b7ef787a98d97069884d3e5166316b09a。源码与元数据由Git保留，原件、云对象和手机文件仍各有恢复来源；资料规模保留9月18日观察。
- 当前metadata（元数据）/current.zip保存4358条目录及cloud-state.json。对desired=1对象的只读聚合为Photos3485图片/116视频、Drive757音频，合计98,570,051,909字节，全部本地state=synced；历史退出行不计当前集合。Photos最新对象记录9月15日07:31Z，provider记录07:48Z；这些是来源保存的本地状态，不是本网页重新访问云端。
- 9月13日102项测试及独立审查只属当时版本；9月18日曾核对新增相册源码、测试定义与已提交元数据。9月22日本轮只读取已发布协作约定，没有重跑测试、模型、上传、照片筛选或手机流程；历史55项验收与画廊保持原日期和字节。
- personal-media-current-acceptance.v1 completed=2026-09-05T10:39:36.6907174+00:00，SHA-256=d2fa41ac8b23ea382502ca222482c87660b8299f5a61e2f2b4a89fa00a89b6be；catalog（目录）=2268d65ca0ce83c4cc7157dd3346993bbd01863fa6eb9bc8dc7e966f41e38636，seed=7745e2a9fbe7872b51f1e0d751436c1aaba694077e6209f8360b21ab339f78f0，phone-plan=3f406f31af445ac2226ff61a33c87df7f0758a2a555cb2513954f5746b85ba7a，cloud-plan=d897ab66d54baae235831ce30359030e5a3c5f1621af2430684e7cea805fb607。以上摘要仅定位2026-09-05那一代目录、种子和计划，供选择该历史版本时核验；不与现行4358条或当前Git源码互证，不在本轮再次声明旧七文件一致。
- catalog（目录）=E:\Media\_manifests\personal-media-current\catalog.sqlite3；seed同根seed\keeper-search-index.ndjson；phone-recovery-plan.ndjson与cloud-candidates.ndjson仍为本地计划。媒体根为E:\Pictures、E:\Videos、E:\Music，录音位于Music\录音；对应G canonical镜像保持同样布局，音乐/铃声不再另设子目录。手机包仍在G:\80_Backup\PersonalMedia\PhoneMediaRecovery\2026-08-25，云远端映射保留在同一SQLite和metadata/current.zip的cloud-state.json。
- AGENTS.md=eea75e071354233adb8780c5639959eb696067e16197945d6378a19bda1be903；README.md=dd60c27ceeac7edc75d2275786442e41220949a098703aaffb27278211e4e7a9；personal_media.py=7bba1e85cd5a7b3ec085191027cbc7bea63824411c8cf2ddf4314191f6506283；phone_file_preserve_clear.py=0ee1b280c5bad9d27dbc483e35faaa5089d6e5c82d1ec791d315dd47dc1200bc；test_personal_media.py=a44d7f3bd4eb30380fe3b356dc4aafdacb10b6cea9ba60310e53a8894a074523；test_phone_file_preserve_clear.py=edc51d9e12a5c1b873852161e8349328ad2a4a7edfa2092c5a68b73416320c34；acceptance.ps1=57b6898cb7063f7d1f7428f55b6acb0221679195a262cf37e3d9a31e00e20a4e。以上是已接受页面保留的2026-09-07历史文件摘要，只有选择对应历史版本时才适用；这些旧字节不再代表当前ba43b4c来源。本轮未重新读取这七份旧字节，不声明它们在9月9日或今天仍一致。
- 手机相册 .globalTrash 是本人已删除原件，既不计入新共享文件保全，也不因图片看起来有用而重新入库或加入手机/云候选。本人在文件管理器删除正式原件后，查询只跳过，既有每日任务再同步目录与恢复面。
- 现有PersonalDataReplica-Hot-Daily维护两库sync-current、E→G镜像与recovery-sync；H按现行备份保留规则跟随G有效保留集，原件/媒体包的实际完成只由备份Owner回执证明。媒体主映射与专用Packages恢复路径分别负责，单一映射成功不覆盖其他路径。当前最终媒体状态三盘证据见备份回执，不连接手机或调用云端。
- 媒体Owner转述备份Owner正式结果：9月14日00:11:27Z十五集合Cold完成；00:15:44.1843808Z补入最终媒体状态后单集Cold再完成。E/G/H catalog（目录）均470,437,888字节、SHA256=d86bce648b585241378527733b7d8ff5da72a966d3b77598cf56cf67cdc048b9。媒体Owner随后只重核E/G，H已离线；网站本轮只读这份有时间的Owner汇总，未重验三盘原件。
当前缺口
- 本人删除原件后，查询只跳过不存在的结果；现有每日备份任务依次更新两库清单、完成 E→G 镜像、同步实际手机包。源根或卷不可访问时不按全库已删除处理，恢复连接后使用同一路径继续；没有新增删除保护、恢复队列或计划任务。
- 当前电脑手机包2245项、43.01GB；本页未取得手机Owner最新回写回执，旧163项只保留历史，不将其升级为当前待办或已完成。
- 本轮没有连接手机；双盘保全、精确清理和恢复写回只展示已实现合同与现行回执，不宣称当前设备动作已经发生。
- 旧手机保全回执的h_cold_backup只描述当时E/G流程；最终媒体状态另有9月14日备份Owner的E/G/H成功时点。本轮没有重验这些载荷，也不混成手机已回写。
- 本地候选、cloud-status所读本地状态与真正远端结果是三层证据；云端完成仅按来源Owner的对象/关系回读，不从旧候选header推断。
- 9月13日全量云回读曾有1段视频PROCESSING；9月18日本地映射观察未取得新平台处理或播放回执，9月22日本轮也未访问云端。当前播放继续Unknown（未验证），不据旧记录断言仍在处理中。
- 当前目录没有全库人物证据；只能在用户选定少量原图后回答可逆的 person:self 问题，不能宣传人物搜索。
- phone-apply 的 review 覆盖、pre-commit 回滚和 post-commit seed/candidate 恢复目前缺少直接 fault-injection 专项回归；三份候选/receipt（执行回执） 文件也不是跨文件原子事务。
- 无法打开、内容意义不明或近重复关系不确定的对象保留为待复核，不因自动化或页面美观直接退出原件。
- 画廊证明这些实拍原图与当前视觉选择，不证明全部地点、类别、设备或媒体库覆盖都具有相同画质。
来源与公开边界
PRIVATE（私有） wlyaaaaa/personal-media，main 22a6109b7ef787a98d97069884d3e5166316b09a。9月22日仅补入已发布协作合同；Git保存源码和可恢复元数据，不保存全部原件。媒体数量、相册、云对象、播放与手机结果保留各自原观察日期，现有画廊不变。
当前关键技术事实
- 当前本地整理结果
- 当前本地目录4358条，仍由照片、视频和音频原件根分别保存。新增具名照片相册是可重建的选择关系，不改变原件分类、不另存第二份图片库；相册用于手机恢复组织与云端关系计划，实际写回和上传另行执行。
- 正式源码与当前阶段
- 9月22日已回读PRIVATE（私有） main 22a6109b7ef787a98d97069884d3e5166316b09a；本次增量仅为AGENTS.md与USER_REQUIREMENTS.md的个人更新协作合同。相册和目录仍沿09e8efb、ba43b4c及9月18日已核对材料，未新建采集器或重跑私人媒体流程。
- 截图文字与画面认知
- 截图细项保留 2026-09-02 观察：15,823 张中，6,440 张带 OCR（光学字符识别） 证据，4,287 张有 visible_text；这不是本轮新增截图覆盖率。当前检索已把确认的处理链/旧路径/哈希移回 provenance（来源说明），真实技术文字与不确定文本保留，避免内部痕迹污染内容召回。
- 三种保留分别决定
- 本地 keeper（保留原件）、Google Photos 云候选和手机携带/恢复资格分别审查。普通新增不会自动进入手机包；严格精选沿用既有资格，普通内容须明确 phone-recovery 及理由。某一批没有合格精选或手机增量为0都是正常结果。
- 录音片段定位
- 选定录音后，locate-audio 复核原音 SHA-256，复用 ChineseASR 已保留的时间段，返回原音起点下的起止时间、逐词覆盖和有限片段；查询不播放、不启动模型、不写库。缺时间时只给单件本地 ASR（自动语音识别） 接续，视频内部定位仍未提供。
- 上次完整云端回读（9月13日）
- 来源Owner于9月13日23:21Z完成最终全量零写回读：Photos3357图片+116视频共76,049,921,114字节，Drive754录音+3音乐/铃声共20,129,267,708字节；合计4230项、96,179,188,822字节。Photos已登记ID均可读、9相册关系一致；Drive完整分页核对ID/SHA-256/大小/父目录一致。
- 检索与耗时边界
- 查询直接使用 SQLite 条件/FTS，返回逐词命中字段、有限片段与范围；当前 source 明确取消 750/250 ms 硬门，不为几秒级耗时牺牲 AI 所需含义和证据。旧精确查询 239 ms 仅是历史观测，不是当前验收阈值。
- 私人版本保存什么
- 当前metadata（元数据）/current.zip保存4358条目录及cloud-state.json。对desired=1对象的只读聚合为Photos3485图片/116视频、Drive757音频，合计98,570,051,909字节，全部本地state=synced；历史退出行不计当前集合。Photos最新对象记录9月15日07:31Z，provider记录07:48Z；这些是来源保存的本地状态，不是本网页重新访问云端。
- 当前技术路径
- catalog（目录）=E:\Media\_manifests\personal-media-current\catalog.sqlite3；seed同根seed\keeper-search-index.ndjson；phone-recovery-plan.ndjson与cloud-candidates.ndjson仍为本地计划。媒体根为E:\Pictures、E:\Videos、E:\Music，录音位于Music\录音；对应G canonical镜像保持同样布局，音乐/铃声不再另设子目录。手机包仍在G:\80_Backup\PersonalMedia\PhoneMediaRecovery\2026-08-25，云远端映射保留在同一SQLite和metadata/current.zip的cloud-state.json。
- 备份任务与现有回执
- 媒体Owner转述备份Owner正式结果：9月14日00:11:27Z十五集合Cold完成；00:15:44.1843808Z补入最终媒体状态后单集Cold再完成。E/G/H catalog（目录）均470,437,888字节、SHA256=d86bce648b585241378527733b7d8ff5da72a966d3b77598cf56cf67cdc048b9。媒体Owner随后只重核E/G，H已离线；网站本轮只读这份有时间的Owner汇总，未重验三盘原件。
完整执行流程
- 1先确定是查找、整理还是个人更新
查找按用户实际提供的地点、文字、类型或日期缩小范围；拍摄地点与画面上出现的地名分开。未限定来源的个人更新把媒体纳入变化发现，先看已有状态与本批数据，不把一句更新变成全库重扫。
- 2直接查当前目录
SQLite 条件与全文索引返回少量结果；普通请求不读取完整 NDJSON（逐行 JSON 数据格式），不扫描整盘。
- 3需要浏览才建临时目录
在 E 盘受管 browse 根创建 task-unique hardlink（硬链接）；原件仍只有一份，目录可精确清理。
- 4本地独立文件走显式 ingest
普通暂存输入位于三个canonical根之外；--register-existing可对中心内明确原件就地登记。两条路线均携带描述并可绑定expected SHA-256。新 keeper 写入 canonical 与 G 恢复副本，等价视频变体先核对 E/G keeper 和 demuxed stream。
- 5手机先做双盘保全
只取得尚未由其他来源负责的新共享文件；分别写入 E 与 G，逐项回读 bytes/SHA-256。
- 6离线做视觉决定
机械预检合并 occurrence、检查可打开性和技术缓存；联系表一次决定 keeper、类别、时间、描述和近重复关系。
- 7把值得重看的原件移入精选
照片精选不设配额，普通视频留在视频根；本人手筛留下者保留，不因不够精选再删除。图片六入口和录音平铺已完成；后续改名/移动保持字节和有效引用，不算瘦身。
- 8事务应用本批决定
phone-apply 要求 review 精确覆盖本批唯一哈希；失败回滚数据库并清理本批新建链接。
- 9同步三面计划
刷新本机目录、G手机恢复包与本地云候选；恢复同步默认dry-run。本地维护本身不调用云端；独立cloud-sync在既有授权范围内处理实际云增量，逐项回读，不逐批重复索要批准。
- 10让备份和恢复包跟随当前文件
sync-current 维护 SQLite、重建种子和既有候选；原 E→G 备份负责镜像，recovery-sync 维护固定手机包和现存视频的格式变体。读取入口不做这些写入，离线后下次从当前集合重新同步即可。
公开分级
普通个人照片按活动公开分级属于 L2；页面逐值处理真实 L3+ 与可复用秘密，不因来源是个人媒体库就整类删除。
本页用到的名词
需要核对专业含义时，可以在这里查看它在 个人媒体整理与恢复 项目中的具体用法。
- Keeper（保留原件）
- 经过可打开性、意义、质量与重复关系判断后，仍承担浏览、唯一性或恢复价值的照片、视频或录音。
- Canonical root（规范原件根）
- 照片、视频、音频的原件中心分别为E:\Pictures、E:\Videos与E:\Music；录音在Music\录音，音乐与铃声在Music根。
- Authority locator（权威原件定位）
- 当前目录中指向现存原件的定位记录；返回候选前仍要确认真实文件存在。
- Exact duplicate（精确重复）
- 完整内容 SHA-256 相同；可以合并 occurrence，但仍要核对唯一性、引用和恢复责任。
- Near duplicate（高度近重复）
- 画面或内容非常接近但字节不同；必须根据主体、清晰度、裁切、时间和版本价值人工判断。
- Contact sheet（联系表）
- 把最多 25 个视觉对象排成一张总览，让一次视觉判断覆盖整批，而不是逐张重复打开。
- Hardlink browse folder（硬链接浏览目录）
- 同卷下指向同一原件字节的临时浏览入口；创建和清理都不复制或删除原件。
- 精选
- 值得本人主动重看的照片一级分类，不设数量配额、不另存副本。现行合同不再设置视频精选目录；历史两类精选计数保留原观察日期。
- File-manager deletion（文件管理器删除）
- 用户自己删原件即生效；查询跳过失效路径，既有计划任务维护清单与派生副本，不增加确认、保护或自动恢复流程。
- upload=0
- 只进入云端候选清单，表示该清单观察时没有执行上传，不代表永久缺少上传能力或后续状态。
系统里实际有什么
下面是当前产品组件，不是概念分类。每一项都对应真实文件、入口或验证链。
当前目录、检索、临时浏览、分类、独立接入、批次应用、恢复包、Photos/Drive对象及关系同步、云删除结算与元数据导出。
目录与状态核心使用 Python stdlib + SQLite/FTS；图片打开/缩略使用 Pillow，视频/音频使用 ffmpeg/ffprobe。snapshot-metadata 只读选定元数据、只写无损 ZIP，不上传或改动原件。项目不新增常驻进程；现有 PersonalDataReplica-Hot-Daily 调用维护和恢复包同步入口，不触发 Git 推送。
手机共享文件捕获、E/G 双盘保全、逐项回读和精确清理。
只处理明确共享边界；删除前再次核对精确路径、大小和哈希，不递归删目录。
保存可重建的当前媒体定位与检索字段。
本次目录4358条，SQLite统一保存定位、分类、检索、具名相册和云对象关系；媒体字节仍由原件与备份保管，历史已退出对象不混入当前期望数量。
重建目录，并分别表达手机恢复与云端候选。
keeper-search-index.ndjson 会在增量收口时原子重写并推进 current_seed SHA，不是跨增量字节不变；它只作当前代重建种子，手机/云 NDJSON（逐行 JSON 数据格式） 是外部计划，三者都不参与日常查询或成为第二 current（当前状态） 索引。
把一批视觉判断压成一个完整、可复核决定。
每张最多 25 个对象；状态必须为 PASS_NATIVE_VISUAL_REVIEW，且覆盖本批全部唯一哈希。
让人查看真实结果但不复制媒体库。
网页画廊使用用户授权的实拍原图和轻量缩略图；本机临时浏览使用同卷 hardlink（硬链接）。
当前数据合同与写读边界
personal-media.catalog.v1 / PRAGMA user_version=1
catalog-build、ingest-file、phone-apply 写；search/browse/plan 读：只保存定位、分类、检索和关系；原件字节在 canonical roots。音频按现行原件布局保存定位，录音在Music/录音，音乐与铃声在Music根；越界或声明漂移失败关闭。meta 绑定 current（当前状态） seed path/hash/rows。
personal-media-search-index-entry.v1 / search-result.v1 / search-index-manifest.v1 / catalog-status.v1 / managed-hardlink-browse.v2
personal_media.py：search 只验 locator（原件定位记录） 存在；精确字节需单项哈希。browse manifest（清单） 绑定 source/link，clean 遇非受管内容拒绝。
personal-media-phone-review.v1 / personal-media-phone-apply-receipt.v1
phone-prepare 生成 review；AI/用户补决定；phone-apply 消费：review 必须 PASS_NATIVE_VISUAL_REVIEW 并覆盖本批唯一哈希；pre-commit 可回滚，post-commit seed/候选刷新不是跨文件原子事务。
phone-shared-user-files-capture.v2 / frozen-delete-plan.v2 / backup-verification.v2 / deletion-receipt.v2
phone_file_preserve_clear.py：绑定 model、serial hash（内容指纹）、profile、fresh run、manifest（清单）/plan hash（内容指纹）、E/G read-back（正式回读）；stale artifact、残留 quarantine 或身份漂移均不能 PASS。
personal-media-phone-recovery-current.v1 / personal-media-recovery-sync-receipt.v1
candidate refresh 写计划；recovery-status 验结构/catalog（目录）；recovery-sync 比实际包：低于 60 GB；录音不进入；execute 按当前清单补齐、更新并清理固定 Images/Videos 桶，不碰 E 原件或桶外内容。
personal-media-cloud-candidate-manifest.v1 / cloud-candidate-current.v1 / product-candidate-refresh.v1
refresh_product_candidates 写；cloud-status 只读：旧候选header的upload_authorized/performed=false只描述该本地清单。正式源码另有同一SQLite中的cloud_object/cloud_membership和cloud-sync状态，不能由候选零上传字段推断账号侧从未上传。
personal-media-ingest-file-receipt.v1
ingest-file：绑定 source/keeper SHA、canonical/G locator（原件定位记录）、source retirement 和候选新增数；cloud_upload 固定 0，失败不能冒充完整收口。
照片原件与显示版本
缩略图用于快速浏览，点开后才加载大图。经过转换或压缩的显示副本与来源原件分别标明，下面可下载网页使用的大图。
显示尺寸 2560 × 1920 · 1,680,364 B · SHA-256 af6d25b5d4afdfe86ea0ce9f9dfaeebfb72e24ddd27fdf86d3445870923499cc
来源原件 4096 × 3072 · 10,396,415 B · SHA-256 440c90890c26f7ccf14495134e6673bfb06abf380b69de93c2258d258ed52439
由现有 JPG 原图缩放为长边 2560 像素的 WebP（网页图像格式）有损显示副本；保留完整构图、方向与原有色彩配置，来源原件保存在媒体库。
显示尺寸 2560 × 1920 · 545,080 B · SHA-256 fa1b98ad91867b2e3b8d2c473f871e4aab980e0df4fa8d4b68203f618d42233f
来源原件 8192 × 6144 · 4,239,666 B · SHA-256 8f25a73f62165e02da020ecd267601fd21636b99a3e956a094b4e99ba1d7d459
由现有 JPEG 显示副本缩放为长边 2560 像素的 WebP（网页图像格式）；保留完整构图、方向与原有色彩配置，属于有损 8 位显示，非无损或 HDR（高动态范围）等价；HEIC 来源原件保存在媒体库。
显示尺寸 1928 × 2560 · 505,050 B · SHA-256 145d935825effae19c6042ba028d9a7d08e8d367c2a96e4056a2b5c0e24d377c
来源原件 6144 × 8160 · 10,547,500 B · SHA-256 cf73efa47d65ed27b4ae1e85fc56667b9e56c463c9731f2c66431564ecce8e43
由现有 JPG 原图缩放为长边 2560 像素的 WebP（网页图像格式）有损显示副本；保留完整构图、方向与原有色彩配置，来源原件保存在媒体库。
显示尺寸 2560 × 1920 · 531,852 B · SHA-256 dbc9f2219cb8374a24f6856bc0b317eda82342581dbb6aa4d90846ccc07a6309
来源原件 4096 × 3072 · 6,987,972 B · SHA-256 02584ec62d4fe3a77003f37b81d58e0f2436e643c5a66abb04f160550a4cb74f
由现有 JPG 原图缩放为长边 2560 像素的 WebP（网页图像格式）有损显示副本；保留完整构图、方向与原有色彩配置，来源原件保存在媒体库。
显示尺寸 2560 × 1920 · 715,226 B · SHA-256 44dff890fd0f57e1799f4a0bf743d0c28a72ee4260b98fe693f0c6aa9149eeb7
来源原件 8192 × 6144 · 14,659,205 B · SHA-256 ed0ada67f8523bf73e90185f8d7d4fdfa4622498fd65a9c91787217f975e4115
由现有 JPG 原图缩放为长边 2560 像素的 WebP（网页图像格式）有损显示副本；保留完整构图、方向与原有色彩配置，来源原件保存在媒体库。
显示尺寸 2560 × 1920 · 247,252 B · SHA-256 a9c57e621f5ea8ccaabf517d04fafc4f2d0fc5cf37cb595531613fc4fe6e64a5
来源原件 5792 × 4344 · 16,297,747 B · SHA-256 745cb711b65641062e53dc5f79a14d185e042474b9529ee9b96ac107c1937cec
由现有 JPG 原图缩放为长边 2560 像素的 WebP（网页图像格式）有损显示副本；保留完整构图、方向与原有色彩配置，来源原件保存在媒体库。
显示尺寸 1920 × 2560 · 624,760 B · SHA-256 04ff98fd3f30d9f5c7458657a71e6b351fd6612db4be5f19e439e75c2aa78ea4
来源原件 6144 × 8192 · 4,261,466 B · SHA-256 a810b90d2c89d585a7f2d2ed9b5adf4dab9155cb25d51c1dbd7116fd6ad307f6
由现有 JPEG 显示副本缩放为长边 2560 像素的 WebP（网页图像格式）；保留完整构图、方向与原有色彩配置，属于有损 8 位显示，非无损或 HDR（高动态范围）等价；HEIC 来源原件保存在媒体库。
显示尺寸 2560 × 1920 · 803,368 B · SHA-256 a8698433790b2647b715e6cb839d93f9d135f64a33c0d2ed93b5727e92eeabda
来源原件 4096 × 3072 · 2,762,779 B · SHA-256 2a88a9f5f653f098ea6fd62bb3cf7347c16a0a726e1fac36a14f0d403cb0e167
由现有 JPEG 显示副本缩放为长边 2560 像素的 WebP（网页图像格式）；保留完整构图、方向与原有色彩配置，属于有损 8 位显示，非无损或 HDR（高动态范围）等价；HEIC 来源原件保存在媒体库。
显示尺寸 2560 × 1920 · 480,720 B · SHA-256 a03dd97b1fb9698d065f06033683982361f4bc74c52f351303be329d09fdd8d7
来源原件 8192 × 6144 · 10,726,082 B · SHA-256 1990afa60bed00ff694ab67bf0a5b9e9bf5b3a5ad002f3f0114921bb7f3097db
由现有 JPG 原图缩放为长边 2560 像素的 WebP（网页图像格式）有损显示副本；保留完整构图、方向与原有色彩配置，来源原件保存在媒体库。
显示尺寸 2560 × 1920 · 421,582 B · SHA-256 1d03756c6a2e7f5d2c77815fb14d90173892ffe4aacd1f47e36c148bf3be8a78
来源原件 4032 × 3024 · 2,817,558 B · SHA-256 cfe48dc969064eabf78a4198b799dc4aaa5f89e0e8179a1f1b595ec6fa73acac
由现有 JPG 原图缩放为长边 2560 像素的 WebP（网页图像格式）有损显示副本；保留完整构图、方向与原有色彩配置，来源原件保存在媒体库。
7 层证据分别证明什么
能证明：9月18日读取ba43b4c已提交的目录与云端元数据：本地4358条、desired对象4358条，3485照片/116视频/757音频。这是保留的聚合观察，本轮没有重新读取私人相册、原件或云ID。
不能证明：网页没有导出或还原真实快照；Git保存分类和远端映射，不保存媒体原件，不能由哈希还原照片。
能证明：既有产品说明定义三阶段手机处理、分类、云执行与查询只读边界；9月22日读取已发布22a6109的AGENTS.md与USER_REQUIREMENTS.md增量，补入一般个人更新及可靠事实/原件定位的既有入口交接，不新增采集器、数据库或后台服务。
不能证明：文字说明不证明当前目录、恢复包或设备在线。
能证明：现行源码实现目录、检索、浏览、批次视觉决定、双盘回读、恢复计划与精确清理。
不能证明：代码存在不证明本轮连接了手机或执行了外部动作。
能证明：ingest-file 为新 keeper 和同视频流容器变体分别定义输入、E/G read-back（正式回读）、目录事务、来源退休与三面候选刷新。
不能证明：入口存在不证明任意未复核文件都应接入，也不证明一次中断可以自动回滚所有外部文件动作。
能证明：2026-09-05旧回执记录55项测试、0失败/错误、2项真机跳过；2026-09-09的383eb854另有4项元数据回归。详细旧指纹仅用于所选历史版本核验。
不能证明：旧回执不证明fb75ce0全部测试通过、今日设备动作或现行全库字节；本轮没有重跑旧验收。
能证明：当前选择的原图真实存在，能够展示旅行、日常和其他视觉类别的画面质量。
不能证明：少量好照片不证明整个媒体库均已逐张人工审美验收。
能证明：2026-09-13T23:21Z全量云对象/分类回读完成且重复执行零写；备份Owner于9月14日00:15:44Z核对最终媒体状态E/G/H一致。
不能证明：9月13日115 READY/1 PROCESSING仅是当时状态；本地synced不证明当前全部播放、手机回写或云端零起点恢复。
维护入口
py -3 personal_media.py ingest-file --source <已在媒体中心的原件> --register-existing --expected-sha256 <SHA-256> --category <类别> --description <说明> --execute就地登记已有媒体原件：只用于已明确复核的中心内文件，保留原件位置；不可与等价变体退休合用，E/G与目录结果仍分别核对。
py -3 personal_media.py cloud-reconcile [--full] [--execute]预览云端期望集合：按当前集合计算Photos和Drive期望对象及相册关系；execute只维护本地状态，不调用云提供者。
py -3 personal_media.py cloud-delete-plan --limit 50定位已退出媒体的云端对象：按内容身份返回精确Photos对象链接，只读不删除；真正删除后再用cloud-settle-retired按已核定SHA-256和网页结果结算，不能把相册移除当成真删。
py -3 phone_file_preserve_clear.py phone-reconcile-deletions --run-id <本次run-id>核对手机删除后电脑需要退出什么：先对照最后完整手机回写事实；加--execute才处理已证手机用户删除。capture在AI清空前接入同一核对，移动、内容漂移和不可读不猜成删除，G/H仍由既有备份跟随。
py -3 personal_media.py cloud-sync --target <photos|drive|all> [--limit 100] [--execute]预览或执行选定云端工作：默认只预览，execute才通过PCConfig提供者工作。本地预览不消费云写授权；执行后分别核对对象、集合关系、删除与未知。当前全量完成依据CLOUD_UPLOAD_RESULT.md，不从代码存在推断。
py -3 personal_media.py snapshot-metadata --output metadata/current.zip按需保存整理元数据：只读重建种子及清单、手机计划、云候选和存在时的候选刷新/手机待清理清单，以 personal-media-metadata-snapshot.v1 保存每文件字节与 SHA-256。原文保真、同内容输出字节不变；源在读取中变化或压缩包超过 100 MiB 时保留旧快照并报错。命令不联网，定向提交和 PRIVATE（私有） Git 推送是后续独立动作。
py -3 personal_media.py catalog-build --seed <恢复目录>/seed/keeper-search-index.ndjson --db <恢复目录>/catalog.sqlite3从所选元数据版本重建目录：先在空目录解压所需 Git 版本的 metadata（元数据）/current.zip，按 snapshot.json 核对文件；换目录时只调整恢复副本 index-manifest.json 的 index.path。这条命令在空目录只重建本地定位与检索，不会导入ZIP中的cloud-state.json；查询成功不能据此替换含云状态的现行库。云端ID/关系的独立导入与从零恢复仍未实现并验收，保留当前数据库和导出的映射，不能丢映射后重传。不覆盖更新数据、不自动执行旧清理清单。移动或改名不改变未修改文件的哈希；编辑或重编码可能改变，单凭哈希不能恢复媒体字节。
py -3 personal_media.py search --place <现场地点> --media-type image --limit 12按线索搜索：返回少量可读候选；普通请求不用 all，也不扫描整盘。
py -3 personal_media.py browse <过滤条件> --browse-root <受管同卷根> --name <任务名> --limit <数量>建立临时浏览目录：创建同卷 hardlink（硬链接） 供浏览，不复制原件字节。
py -3 personal_media.py clean --folder <精确受管目录>清理临时浏览目录：只删除该浏览入口；目录混入非受管内容时拒绝。
py -3 personal_media.py locate-audio --sha256 <原音SHA-256> --query <原文线索> --limit 5定位选定录音内容：只读复用同原音的已有 ASR（自动语音识别） 时间段，返回范围和有限片段；不启动识别、不播放，不支持视频内部定位。
py -3 personal_media.py ingest-file --source <已复核文件> --expected-sha256 <SHA-256> --category <类别> --description <说明> [--formation-date YYYY-MM-DD] [--tag <标签>] --execute接入一个本地 keeper：写入 canonical 与 G 恢复副本、更新目录并刷新手机/云候选；源文件最终退休。
py -3 personal_media.py ingest-file --source <变体视频> --expected-sha256 <SHA-256> --equivalent-keeper-sha256 <keeper SHA-256> --description <说明> [--tag <标签>] --execute退休等价视频容器变体：只有 E/G keeper 与 demuxed video stream 完全核对后，保留 G 变体恢复副本与关系并退休来源。
py -3 personal_media.py phone preserve-clear plan确认是否需要 fresh 捕获：没有 run-id 时只返回 CAPTURE_REQUIRED，不列 live 候选，也不捕获、复制或删除。
py -3 personal_media.py phone preserve-clear plan --run-id <run-id>读取既有冻结计划：只读核对该 fresh run 的 manifest（清单）、delete plan 与边界；stale/invalid artifact 要求重新 capture。
py -3 personal_media.py phone preserve-clear status --run-id <run-id>快速查看一次手机 run 的已记录状态：只读汇总 capture/plan/backup/delete artifact 是否存在及 JSON 内已记录的 safe_to_disconnect、phone_clear_complete；不验 embedded hash（内容指纹） 或当前 E/G 字节，也不判断 stale，完整 artifact 验真必须运行 plan --run-id。
py -3 personal_media.py phone preserve-clear capture捕获到 E 盘并冻结计划：取得本次新共享文件、写入独立 E 副本并返回 immutable run-id；尚未完成 G 双保全。
py -3 personal_media.py phone preserve-clear protect-to-g --run-id <run-id>写入 G 异卷副本：按冻结计划写 G 副本；仍需 verify-backup 才能宣布双盘保全完成。
py -3 personal_media.py phone preserve-clear verify-backup --run-id <run-id>核验双盘保全：逐项回读E/G字节与SHA-256；通过表示数据已双盘保全。按三阶段流程还需收稳本次精确清空才告知第一阶段结束可拔，不自动证明清空或回写。
py -3 personal_media.py phone preserve-clear delete --run-id <run-id> --execute精确清理手机文件：另行核对精确路径、大小、哈希和冻结计划后删除；不递归删目录，也不表示恢复出厂。
py -3 personal_media.py phone-prepare --run-id <本次运行>准备视觉批次：一次机械预检并生成每张最多 25 个对象的联系表。
py -3 personal_media.py phone-apply --review <review.json>应用视觉决定：事务应用完整 review，并在同次收口更新目录、恢复包与云候选。
py -3 personal_media.py sync-current同步当前清单：现有每日备份任务调用的本地维护：只按当前原件清理索引、种子和既有候选，不连接手机、不上传云、不自动填补其他历史候选。
py -3 personal_media.py recovery-status查看手机恢复状态：只读返回当前封印计划、数量、大小与缺口。
py -3 personal_media.py recovery-sync [--execute]同步手机恢复包：默认只预览；执行才补齐或更新计划内文件、移除固定 Images/Videos 桶内过时派生文件，不碰 E 原件或包外文件。
py -3 personal_media.py cloud-status查看云候选聚合状态：只读汇总本地Photos/Drive期望对象及集合关系的synced、pending、unknown（未验证）、failed、paused数量、上传/待传字节及退出状态；provider_status_source=local_state_only，不访问账号、不上传，不能替代远端回读。
py -3 personal_media.py catalog-build --replace重建当前目录：从当前代原子 seed 重建可删除 SQLite，并由 acceptance.ps1 重新验收。
快照怎样更新
本页在个人媒体项目的查找、分类、手机保全、恢复、云候选、公开画廊或用户决策边界发生实质变化时更新。普通媒体增量按既有授权更新原件、目录、恢复和云端对应状态；如果产品能力与公开解释仍然成立，不把每张新增照片变成网站更新日志。