[xiaoland]

让原版 x-monkey 的 User/Post/Media 进入共享 info-base，并在关闭脚本后继续检索、阅读和按需展开媒体。配套 impl-py #145、docs #38。

按 架构 review 及后续修正 收敛边界：

• Twitter 拥有共同模型、身份与合并规则；x-monkey 固定 DTO 和逐项状态留在来源 Adapter。已有 JSON、Resolver ID、Block ID 和引用兼容。
• Resolver 选择图片或最高码率 MP4 并管理 Blob；HTTP(S)、大小、超时和重定向由既有 HTTP Storage 负责。仅保存媒体元数据，展开前不读取本体，不创建下载 Job。
• 首次连接由 Core 自托管账户页完成。用户输入已有部署 Secret，页面仅在内存用 WebCrypto 签 60 秒普通 Peer JWT，以同源 Bearer fetch 建立既有归档 Cookie，再检查实际会话。Web 仅提供账户页普通链接，不处理凭据交接；不依赖 Web/MF 完成首次连接。

已撤回本次新增的 browser-form、PeerAuth、专用能力广告及配套预览/CI版本准备代码。Twitter MF 保持 >=0.4.0 <0.5.0，当前预览直接构建源码 Core0.4.0 / MF0.4.2；Core patch Changeset 保留独立的普通 Web JWT24小时签发默认值修改。

验证：本地完整 pnpm check、原有 MF 分发检查通过；最终 Client checks 全绿。相对任务基线1e4e38b，tests/ 和默认 Playwright 配置无改动；新增候选验证仅在 scripts/tests，不接入默认集合。

新路径 pnpm verify:twitter 1/1通过（2.2分钟）：全新浏览器状态先直接打开Core账户页，实际WebCrypto签名→同源Bearer→真实Cookie会话→Cookie保存/query，且Secret未进入页面请求或Core local/sessionStorage；之后才配置独立Web Peer/MF，验证持久形状、索引检索、内容阅读、展开前零读取、503反馈、其他图片来源及最高码率MP4/Blob。

另在Helium实际通过新Core页面连接，显示Connected、core-py-pr-145及7天到期时间；截图已保存。原版油猴的本轮重新检测因输入控制问题未完成，临时未保存地址已撤销；此前真实脚本保存/重放/续签仅作为未改协议的既有证据，不冒充本轮新连接路径的油猴验收。

预览 产品对应源码8f6f09b，最终40f5849只修正手动验收脚本、产品源码无差异，使用普通 exact-head 流程，未消费 Changeset 或发布正式版本。JWT仍具完整Peer权限，断开只清Cookie；媒体URL失效会明确报错。回退采用后续兼容提交，不清空数据；未合并或生产发布。

[xiaoland]

这组 PR 已经跑通 x-monkey → InKCre → Info Base 的集成链路，但我认为仍存在一些需要在合并前解决的架构边界问题。重点是模型所有权、依赖方向，以及认证与安全策略的职责归属，而非再增加局部测试或防御性校验。

1. InKCre 必须拥有自己的 Twitter 信息模型

当前实现几乎直接采用 x-monkey 的归档 Schema，并将其上升为跨 Python/Web Distribution 的持久数据契约。TS schema.ts 甚至保留了描述「x-monkey 内存库 / tweet-db 线上格式 / source object」的上游注释；共享契约还将 x-monkey 的特定版本作为 wire 字段和合并语义的基线。

x-monkey 只是一个导入来源。我们还有 X 官方 API、Twikit，未来也可能有其他 Provider。事实上，配套 Python 实现已经将这些来源适配为同一 ArchiveBatch。这表明当前的依赖方向值得重新审视：外部采集工具的内部模型正在反过来决定 InKCre 的持久信息模型。

可以充分借鉴 x-monkey 的 User/Post/Media 设计，最终字段甚至可以高度一致；关键是由 inkcre/twitter 基于 Twitter 信息本身的语义定义、拥有并演进规范化模型及身份/合并规则，由各来源的 Adapter 负责转换。各 Provider 原始数据可以按需完整保留，独立于 InKCre 对共同语义的解释。后续支持 X API/Twikit 的新事实，不应反过来受制于 x-monkey 的内部 Schema 或发布节奏。

希望先明确这层模型所有权与适配边界，再固化跨 Distribution 的持久契约。

2. 安全控制需要对应真实信任边界，避免业务层额外收紧通用能力

InKCre 已有明确的单部署所有者、对等 Peer 权限模型，以及 Storage/Resolver 的职责分工。按照现有 Security Boundary Model，新增安全控制应说明 actor、asset、可信的攻击路径与边界，以及控制成本。

例如，ArchiveMediaResolver 硬编码 pbs.twimg.com / video.twimg.com 的精确域名白名单，使来源已接纳的媒体 URL 在阅读阶段又接受一套 Twitter 专有的准入判断。HTTP Storage 已承担字节获取、超时和大小限制；若还需要限制网络访问目标，请说明具体威胁模型，并明确由哪个层负责该策略。否则会让合法的其他来源/CDN 数据在阅读时受阻，且把网络安全策略耦合进内容解释器。

类似地，x-tweet-db-client: x-monkey 适合作为 x-monkey 兼容协议的要求；若定位为通用 Twitter Archive 接入能力，就不应让其他 Provider 冒充 x-monkey 的客户端身份。请区分兼容适配协议与 InKCre 自身的能力契约。

3. Peer 凭据与浏览器会话交接不应由 Twitter Setup UI 自行实现

现有 Web 本身是 Peer，能够签发普通 Peer JWT；Core 也已经负责签发和续签归档会话 JWT。我不建议以此引入「所有 Peer JWT 统一由 Python Core 签发」的中心化依赖。

真正的问题是 twitterSetupWizard.vue 直接调用 authStore.refreshToken()，再自行拼接 Core 提供的 URL、构造 Form，并将完整权限的 Peer JWT提交给目标。已有的 Peer delegation 负责能力发现、目标路由和认证，但这里另起了一条直接 HTTP 的业务调用路径。

顶层 Form POST 可能是建立 HttpOnly Cookie 的合适浏览器传输方式；这不意味着目标验证、凭据交接、导航编排及其安全策略应由单个 Extension 的 UI 实现。希望解释现有 Peer delegation/认证基础设施在这里缺少什么语义，并考虑将会话交接抽象成可复用的 Peer/认证能力，让 Twitter Setup 只表达连接意图，同时保持当前对等 Peer 的架构边界。

---

总体要求：先明确内部信息模型、来源适配、Resolver/Storage、Peer 认证与 Extension UI 之间的所有权及依赖方向，再决定代码如何调整。功能验收已经提供了有价值的证据，但这里的问题属于长期架构约束，建议在合并前处理。

[xiaoland]

已按这三项边界完成修正，并同步了配套实现和共享合同。

1. 共同模型与来源协议分开。 Python 新增 Twitter 自有 model.py，Official API/Twikit、持久化和 Resolver 均使用它；x_monkey.py 在边界转换固定 DTO，并产生协议状态。旧协议导出只投影它支持的字段，未来共同模型新增事实不会被旧 wire 格式反向限制。当前未引入原始响应存储，未映射字段也不再被文档宣称为已保留。已有 JSON、Resolver ID、Block ID、presence、计数及事务行为保持兼容。见 impl-py 修正 和 共享合同。
2. 内容解释与网络读取分开。 Resolver 保留图片/最高码率 MP4 选择与 Blob 生命周期，把 HTTP(S)、超时、大小和重定向交给既有 HTTP Storage，删除精确 CDN 等业务层限制。x-tweet-db-client: x-monkey 只属于兼容接入协议，其他 Provider 不经过该入口。
3. 凭据交接归 Host/Auth。 现有 delegation 使用 fetch/JSON 请求响应，缺少顶层导航及 Cookie 接受的语义，因此增加可复用的 browser-form 传输，而不是把它伪装成普通 JSON 委派。Host/Auth 从用户所选的存活 Peer 和精确能力广告确定目标、内部签发现有 Peer JWT 并顶层 POST；Twitter UI 仅提出连接意图。结果只表示 initiated，实际会话由账户页/客户端检查确认。各 Peer 的本地签发能力保留，Cookie 与续签政策仍属 Twitter。主要源码见 c78007a。

新 SDK API 的真实最低版本为 0.4.1。保留该下界，并复用 Changesets 在隔离候选生成 Core 0.4.1 / MF 0.5.0；没有手改正式版本或放宽准入。也修正了既有 native MF 检查的构建输入，最终 CI 全绿。

验收包括 74 项独立 PostgreSQL/HTTP 脚本、12 项手动 handoff/版本脚本，以及新配套预览上的真实 Chromium → Host API → 顶层 POST → Core Cookie → 保存/query → MF 阅读/索引检索，1/1 通过；独立图片与视频 CDN、零预读、失败反馈和最高 MP4 选择已覆盖。新增验证全部留在 scripts/tests，没有加入正式 tests 或默认测试集合。此前真实油猴续签证据继续作为未改 Cookie 协议的证据，本轮不声称重新执行过油猴续签。

体验预览（派生自 a86e617，不是已发布的正式版本）。未合并或发布生产。

另已在原有 Helium 标签将 MF 更新并确认 Running 0.5.0，通过新 Host/Auth 路径到达 Core 的实际已连接账户页；未修改 x-monkey 脚本或其配置，已保存交接成功截图。

[xiaoland]

补充并修正此前 Review #5580358983 的第 3 点。进一步检查原版 x-monkey 的凭证需求、浏览器 Origin/Cookie 机制，以及当前已经新增的 PeerAuth.navigateWithCredential / core.peer.protocol.browser-form.v1 后，我认为无需为这个连接场景引入通用的跨 Peer 浏览器凭据交接协议。

x-monkey 本身只要求 Archive Backend 提供 GET /api/v1/session、未连接时的 account_url 和后续随请求携带的 Session Cookie。它无需持有 Peer JWT，也不需要 InKCre Web 参与授权。

建议采用 Core 托管连接页 作为目标方案：

1. x-monkey 按现有 account_url 打开 Core 自己的 /twitter/x-monkey/account。
2. 用户在此页输入该部署的 JWT_SECRET；页面在浏览器内使用 Web Crypto 按现有 Peer JWT 契约签发一个短有效期的 JWT。Secret 只留在页面内存，不传给 Core、不持久化，也不加载第三方脚本处理它。
3. 页面通过同 Origin 的 fetch()，以 Authorization: Bearer <JWT> 向 /twitter/x-monkey/session 提交短期 JWT（credentials: 'same-origin'）。Core 为该接口复用现有 require_peer_jwt 鉴权依赖，验证成功后签发归档 Session JWT，并在响应中 Set-Cookie。浏览器可以直接接收 Core 自己的 Cookie，无须顶层 Form POST、跨站 Cookie 交接或新的 Peer transport。对应地需要将现有 /session 的 Form Body 接口调整为 Bearer 鉴权。
4. Core 继续拥有归档 Session Cookie 的签发、有效期与续签；x-monkey 继续使用原有 query/submit 协议，无须修改脚本。

我也比较了另外两条看似更便捷的路径：Web 直接签发归档 Session JWT，或由 Web 通过 Peer delegation 请求 Core 签发。前者仍须把凭证安装成 Core 域名的 Cookie，后者也一样；若要求跨 Origin 一键免输入，最终仍需要某种交接。这只是可选的低频操作 UX 优化，不值得为此扩展 Peer transport/Host Auth 的公共契约。 用户在连接时手动输入一次部署 Secret 是可以接受的明确取舍。

因此建议移除本次为该场景新增的 browser-form Peer 协议、Host/Auth handoff API 以及 Web 端的 JWT 交接路径；让 Web 只提供 Core 连接页的入口（如确有需要），真正的连接流程由 Core Twitter Extension 自己拥有。已有归档数据、Session Cookie 语义和 x-monkey 兼容接口可以保持不变。

[xiaoland]

已改为 Core 自托管连接页，并撤回上一轮通用交接实现。本回复取代上一条回复中的第3点及SDK/版本准备说明；共同模型和Storage职责的修正保留。

• /account 在内存用 WebCrypto/HS256 将已有部署Secret签为60秒普通Peer JWT，固定同源Bearer fetch /session；后者复用 require_peer_jwt 建立原有归档Cookie，再GET session确认浏览器实际接受Cookie后显示Connected、Peer和期限。
• 页面不持久化或发送Secret，不加载第三方脚本；CSP只允许nonce脚本和同源连接。文档明确只能在自己的可信HTTPS部署输入Secret，不能以“本地签名”保证恶意页面安全。
• 删除browser-form协议/schema、PeerAuth API、仅此使用的能力解析、Python能力广告和Web JWT交接；Web保留普通账户页链接。7天默认值、半寿命续签、Cookie属性及x-monkey query/submit合同保持。
• MF下界恢复 >=0.4.0 <0.5.0，删除为新API增加的preview/CI版本准备器、专用脚本/测试与文档。原Core0.4.0/MF0.4.2直接通过分发检查；Core patch保留普通Web JWT24小时默认值的独立改动。

Python e55bed3、TS 8f6f09b及共享合同ff82097已推送。TS后续40f5849只修正候选脚本的header读取，产品树不变。

验证：Python16项HTTP、Ruff/Pyrefly，完整pnpm check、原有MF分发检查、两套producer文档构建/pack通过。新预览上真实Chromium端到端 1/1通过（2.2分钟）：全新context直接Core连接、Secret网络/存储检查、Cookie读写、独立Web/MF阅读和索引检索、按需媒体。另在Helium新Core账户页实际完成连接并保存截图。所有新增验证仍在scripts/tests，正式tests和默认测试集合无新增。

本轮没有完成原版油猴重新检测（输入控制问题，未保存地址已撤销），不以旧证据冒充新连接路径的油猴验收；此前真实GM保存/重放/续签保留其未改协议的适用范围。Web预览 · Core账户页。最终完整CI与最终Pages均通过。未合并或正式发布。