askairo Media Ops
把账号目标、平台机制和内容主体转化为可执行的素材发现与发布任务，并协调平台子技能完成核验、筛选、改编和发布。外部自动化任务的 RRULE 是运行频率的唯一权威；配置不得再用目标计划时间、最小间隔、每日上限或媒体获取次数把一次已触发的运行挡掉。运营反馈由独立的 media-loop 负责；media-ops 只消费其经过证据支持的策略覆盖，不在发布流程中自行猜测效果原因。
media-ops 是发布执行层总控，不是运营策略层总控。直接发布请求、已明确的目标级执行任务和由 media-loop 路由来的配置落地任务进入本技能；“为什么效果差”“应该改哪个配置”这类未分类问题先交给 media-loop 诊断。media-ops 只能在用户明确授权长期生效时修改常驻执行配置，其他反馈只作为本轮或下一轮的临时覆盖。
涉及可复用内容资产时，先读取 media-core 的内容资产、证据卡、生命周期和分发目标规范；media-ops 负责调度和发布，不把平台账号配置写回内容资产的共同真相。
Resolve configuration
执行前读取 configuration.md，按其中的配置位置、模型、合并顺序和校验规则解析运行上下文；运行阶段、检查点和恢复规则遵守 media-loop 的 runtime-contract.md。
若配置提供 docsRoot，将其作为外部运营文档根目录；按 <docsRoot>/<platform>/<account>/ 读取和写入队列、发布历史、运行记录和复盘。外部文档是人类可读记录，本地状态是机器执行缓存；两者不一致时停止推进并记录待核对状态。
若平台 operation 提供 editorialFrameworkRef，先读取 media-core 内容层主题框架，再交给平台子技能做适配；若提供 coverSpecRef，只在需要生成或核验该平台账号视觉资产时读取。主题框架和平台视觉规范职责分离，不能把平台规则回写到内容层。
先做调度权威检查：内容优先模式下，每个内容 pipeline 只能由一个来源生产任务写入候选；统一扫描器和现有平台定时器都可以触发，但必须进入同一个 media-ops 决策入口，并共享 contentId + targetId 运行锁。平台定时器保留原有发布能力，资源为空时应调用 media-loop → media-core 有界补货，再回到对应平台子技能发布。发现触发器绕过全局决策、同一 pipeline 存在两个生产者、未持锁写入或内容层游标与平台队列互相宣称拥有顺序权时，返回 scheduler_authority_mismatch，不打开发布页、不上传、不点击发布。
配置采用“账号共性 → 平台 operation → 执行 strategy”的层级。media-ops 只负责解析和校验这套结构；平台推荐机制、发现关键词、候选信号和内容形态由对应子技能根据运行上下文决定。
选择一个逻辑账号；一个逻辑账号只能代表一个品牌/运营主体。若存在多个账号且用户未指定，不要混合运行，先询问选择；不同定位、受众或内容支柱的账号即使属于同一用户，也必须分别运行。
解析该账号启用的平台身份、平台风格、数据源组和执行策略。
解析
platformAccounts.<accountRef>.browserProfileRef和平台 operation 的执行传输；浏览器平台必须先路由到绑定的 Chrome Profile，再核对平台公开身份。API 平台不需要 Chrome Profile。允许用户在本次请求中覆盖配置；仅覆盖本次运行，不自动回写配置文件。
- 本轮不再创建“频率豁免” lease；每次外部触发都是独立的尝试。仍不得把触发本身解释为关闭健康、事实、版权、去重、媒体可用性、平台真实限流或成功核验门禁。
若缺少的信息只影响表现形式，采用保守默认值并列明；若缺少账号定位、来源、目标平台或浏览器 Profile 路由会改变执行对象，停止并返回具体缺失字段。
不读取或保存密码、Cookie、访问令牌等凭证。Profile 配置只保存本机可见的环境标识和切换方式，不保存认证材料。
形成运行上下文：账号定位、平台、运营目标、内容主体、受众、来源边界、平台目标、发布策略和浏览器 Profile 路由。上下文不完整且会改变选材结论时停止，不用通用热点替代。
若存在有效的
media-loop反馈，读取最近一次健康状态、策略版本、实验状态和未决门禁。账号被标记、限流或发布状态不明确时，先执行反馈中的暂停/降频要求；不得用新一轮内容覆盖账号健康风险。
Route the browser Profile
- 浏览器平台的执行对象由
platformAccountRef → browserProfileRef → platform handle唯一确定；同一平台的不同账号不得共用一个 Profile 路由。 - Chrome 浏览器操作只能使用配置的
chrome-mcp（Chrome MCP/browser-client）或playwright-mcp（Playwright MCP Bridge）。chrome-mcp先从openTabs定位目标profileName的已登录 Tab 并claimTab；playwright-mcp则要求用户先在目标 Profile 中启用 Bridge 并授权已登录 Tab。不得猜测或切换 Profile，也不得使用桌面点击、Computer Use、CDP、鼠标坐标点击或其他浏览器控制接口。 - 接管后重新打开平台入口，读取当前登录 handle、账号名和平台身份。任何一项与配置不一致、页面仍在旧账号或目标 Tab 不可确认时，立即停止，不创建草稿、不上传媒体、不发布。
- 两种通道均要求目标 Profile 的已登录 Tab 可确认；
chrome-mcp无可claimTab的 Tab 或playwright-mcp无 Bridge 授权 Tab 时，返回profile_route_missing，不得创建未核验会话或在两种通道间静默回退。 switchMethod: chrome-mcp表示 Chrome MCP 识别并接管既有 Tab；switchMethod: playwright-mcp表示用户授权既有 Tab 后由 Playwright MCP Bridge 接管；current-session只表示沿用当前已确认的单账号 Tab，不能用于同平台多账号无人值守路由。- 在提供 Unified Computer Use/
cua_repl的新版运行时中，chrome-mcp对应cua.getState()返回的family: chrome、type: extension浏览器及其cua.getTab(...)Tab API。使用该 Chrome extension Tab 的可访问页面读取、输入、上传和导航仍属于 Chrome MCP 通道，不是 Computer Use 回退；不得改用cua.getApp("Google Chrome")、桌面坐标或原生窗口点击。旧版独立工具名不存在本身不能判定profile_route_missing。
Resolve the execution transport
operation.transport标识平台适配器；interactiveSkill/scheduledSkill标识交给哪个平台子技能；interactiveTransport/scheduledTransport标识该次运行实际使用的执行通道。scheduledTransport对所有需要写入外部平台的定时任务都是必填。浏览器平台只允许显式的chrome-mcp或playwright-mcp；API 平台必须选择已接入的official-api。平台子技能可以进一步限制可用值。chrome-mcp或playwright-mcp表示 Profile 路由、页面读取、输入、上传、编辑、发布控件、结果核验和 Tab 清理全部由同一已声明通道完成；不得在两者之间静默转换，也不得转换为 Computer Use、controlled-browser-session、CDP、鼠标坐标点击或其他 Chrome 控制接口。official-api不打开 Chrome，必须由对应 API 子技能完成身份和结果核验。switchMethod: chrome-mcp或playwright-mcp与interactiveTransport/scheduledTransport必须分别写入运行快照，但都不得指向其他浏览器执行器。- 运行时预检先发现当前可用工具：若有 Unified Computer Use，则读取 browser inventory，选择
family=chrome且type=extension的实例，再按目标站点 URL 取得既有 Tab；只有没有 Chrome extension browser/目标 Tab，或页面实读账号与配置不一致时，才返回profile_route_missing/account_mismatch。不得仅检查旧工具名称后提前失败。 - Chrome extension inventory 不暴露
profileName时，只有一个 extension browser、其中存在目标站点 Tab、配置 Profile 已验证且页面实读 handle 匹配，才能记录本轮 browserId / extensionInstanceId 并继续；多个 extension browser 无法映射到配置 Profile 时停止，不猜测。 - 缺少、拼写错误或当前平台不支持的传输不得静默回退；返回
scheduled_transport_missing或scheduled_transport_unsupported，不打开发布页、不上传、不点击发布。 - 运行记录必须写入
activeTransport、interactiveTransport/scheduledTransport和browserProfileRef，便于区分配置门禁、浏览器连接问题和平台发布问题。
Content-driven dispatch and Profile batching
当任务由内容分发触发时，先读取 media-core 内容资产和未完成的 distributionTargets，再解析每个目标的 platformAccountRef、平台策略和 browserProfileRef。定时器的执行对象是内容目标，不是某个平台技能本身；外部触发时间决定本轮是否尝试，不再等待目标的计划时间。
- 统一分发定时器和平台定时器都可以触发同一决策入口；触发器当前 RRULE 决定运行频率。
plannedAt/preferredWindow仅保留为排序、审计和内容计划信息，不是发布阻断条件。 - 在进入浏览器前，确认内容资产已经通过
media-core的 ready admission check；扫描器不得把verified资产提升为ready，也不得为缺少到期字段的目标临时补写发布时间。 - 对每个目标检查 ready 状态、账号身份、事实、版权、媒体、去重、运行锁、平台真实限流/挑战、失败中的不确定状态和
media-loop健康门禁。不得再检查minIntervalMinutes、maxPublishedPerDay、目标时间窗口或媒体获取次数。maxPublishedPerRun仅是单次触发的批量保护，不是时间或频率门禁。 - 同一平台不同账号和同一账号不同平台仍分别记账；全局扫描器的
maxTargetsPerRun只是单次触发的资源保护。平台返回的真实 rate limit、账号标签、挑战和安全暂停仍必须尊重，不能由配置关闭。 - 同一内容的多个目标可以覆盖不同平台、账号和格式；平台策略中的旧时间字段不再作为目标级阻断条件。
- 解析完目标后，先按
scheduledTransport，再按browserProfileRef分组，并在同一传输和 Profile 内尽量连续处理不同平台目标，减少路由切换；分组只改变执行顺序，不改变目标边界。 - 即使多个目标使用同一个 Profile，每个目标进入平台后仍必须重新核对公开账号身份。不能因为 Profile 已确认，就跳过
platformAccountRef → platform handle校验。 - 一个 Profile 可以承载用户已确认登录的不同平台账号；同一平台的不同账号不得默认共用 Profile，除非平台支持可靠的账号切换且配置明确授权。账号不匹配、Profile 不明或切换后页面仍是旧账号时，立即停止该目标，不影响其他目标按独立状态处理。
- 每个目标独立写入
publishState、帖子 URL、指标和失败原因。不能把“同一内容部分平台成功”汇总成一次全局成功，也不能把一个平台失败扩散为所有目标失败。 - 同一账号的多个未完成目标按
media-core.dispatchScheduler.targetSelection处理：选择最早plannedAt的未完成且 eligible 目标；同一时间再按targetCreatedAt、sourceObservedAt、targetId排序。不得因为新资源刚在另一个平台成功，就改选最新资源；已在小红书完成的目标不影响同一内容在抖音上的独立未完成目标。目标级不 ready/适配失败可以保留并检查下一条 eligible 目标，账号级健康阻断则暂停该账号队列。
Preflight and resume
进入来源访问、媒体上传或平台写操作前，先建立一次运行检查点，确认账号、目标、传输、来源证据、媒体状态、幂等键和运行锁。若同一 contentId + targetId 已有未完成运行：
- 已明确发布成功、审核中或已写回：直接结束，不重复发布；
- 已有草稿或上传产物：从最近的明确阶段继续，不重新发现、下载或创建资产；
- 发布结果不明确：只读核验，不点击发布；
- 仅有可恢复的连接/页面错误：只恢复受影响阶段，达到预算后转为具体
blocked或unknown。
每个跳过、失败和待确认结果都必须写出 reasonCode、nextAction 和 resumeCondition。不要用“本轮没有内容”掩盖配置错误、适配积压、账号暂停、数据不足或运行时故障。
Historical result reconciliation does not fulfill the current run
平台时间线可能已经显示某个本地 pending 目标在更早的运行中成功发布，而本地队列、游标或台账尚未回写。此时只读核验并修复本地状态属于历史结果对账，不是本轮新发布：
- 先用标题/正文/媒体或时长、账号和平台发布时间把历史作品与
contentId + targetId明确关联，再写回published/published_pending_review和顺序游标；不得重复上传或点击发布。 - 记录
historical_result_reconciled、作品实际发布时间和newPublishSideEffectsThisRun: 0。历史作品发生在本轮runStartedAt之前时，不消耗本轮maxPublishedPerRun，也不能被写成“本轮已发布”。 - 对账完成后必须在同一轮重新扫描当前账号的未完成目标。如果本轮是用户明确要求发布一次，或当前触发器的目标是推进一次平台发布，而仍没有本轮关联的新提交，则继续执行空队列恢复：先交给
media-loop判断，再由media-core恢复适配或生产，最后重新扫描并最多新发布 1 条。 - 用户说“今天发布”时，以账号配置时区比较平台
publishedAt的自然日；前一自然日的历史作品只能完成对账，不能满足今天的发布请求。不得用固定每日上限或最小间隔替代这一判断。 - 只有账号健康暂停、结果不确定、来源/版权/媒体硬门禁、无合格候选、幂等冲突或有界恢复停止条件命中时才结束；结束记录必须区分“历史对账成功”和“本轮新发布未完成”。
Shared runtime contract
运行结果分类、检查点、未知副作用和恢复语义统一遵守 media-loop runtime contract。本技能只补充发布执行阶段规则，不另建同义结果类型。
Run the workflow
如果调用上下文已经提供 contentRef 或 distributionTargetRef，先读取 media-core 内容资产和目标状态，不重新做与该内容无关的平台热点发现；只在证据、目标窗口或平台适配信息缺失时补充发现。只有没有现成内容资产时，才从候选发现开始，并在核验通过后建立内容资产和分发目标。
1. Build the discovery brief
- 先解析目标账号与平台的运营上下文，再调用对应平台子技能生成
discoveryBrief；不得先用统一的“热门内容”搜索覆盖所有平台。 discoveryBrief至少包含：内容主体、平台推荐目标、首要行为信号、候选来源、搜索主题/关键词、排除项、版权边界、时间窗口和候选排序依据。- 平台子技能可以把“是否值得找”定义为平台专属问题：例如 X 关注讨论、引用、主页访问和关注转化；抖音音乐账号关注音频适配、前三秒记忆点、画面可编辑性、完播潜力和版权；小红书关注搜索意图、收藏价值和卡片信息密度。
media-ops负责校验discoveryBrief是否符合账号配置、来源与安全门禁，不改写平台目标，也不把所有任务降级为追逐总阅读量。
2. Collect source candidates
- 按账号引用的数据源组采集；显式提供的素材作为本次运行附加来源。
- 按
discoveryBrief指定的顺序采集；若目标平台为 X，检查账号首页/近期时间线中的高价值候选，再扩展到官方名单、原始作者、主题搜索和趋势发现；其他平台按各自子技能的来源策略执行。 - 优先使用配置的可信名单、官方公告、原始研究和作者原文；仅在策略允许时扩展到主题搜索或趋势发现。
- 对热点、平台规则、产品信息和其他时效性事实进行实时检索，不依赖记忆；平台专属规则交给对应子技能。
- 为每项候选记录标题、发布者、发布日期、URL、来源类型、核心主张和与账号定位的关系。
- 对视频、播客或访谈，优先取得带时间戳的原始转写；无法直接核对时降低置信度。
- 遵守站点访问规则、平台 API 条款和版权边界，不绕过访问控制。
热点发现的最小记录应包含：检索时间窗口、排序依据（浏览量、互动量、增长或平台明确的趋势信号）、原帖链接和可见指标。记录绝对指标与归一化指标（如互动/阅读、收藏/阅读、回复/阅读），不要把搜索结果页的顺序或总阅读量直接等同于“热度最高”；优先选择官方账号或原始作者的帖子，并用独立来源交叉核对核心事件。
- X 推荐策略的长期参考见目标平台子技能的增长参考；候选评估应覆盖账号相关性、陌生人理解成本、用户价值、可信度、新鲜度、原创增量、平台适配度，以及可能触发的回复、转发、引用、点击、主页访问、停留和关注行为。不得声称掌握线上固定权重。
3. Normalize and deduplicate
- 按同一事件、研究或原始声明聚类，不把转载和评论误认为独立证据。
- 找出最早或最权威的原始来源，将二手材料仅作为背景、反应或补充视角。
- 区分事实、推断、观点和传闻；在后续草稿中保持这种边界。
4. Verify and score
读取 source-quality.md，执行其中的来源层级、核验门禁和 100 分评分。
- 关键事实必须能回溯到来源中的具体段落、数据、页面或时间戳。
- 高影响或存在争议的主张需要两个相互独立的可靠来源；多个转述同一原文的页面只算一个来源。
- 不能核实的内容不得写成事实。将其排除，或明确标记为待核验线索。
- 记录淘汰理由，避免为了凑数量降低标准。
- 使用执行策略配置的候选数量、最低分和入选数量；不可配置项不得放松事实与安全门禁。
- 保留通用核验分与平台专属分；通用分判断可信度、版权和安全，平台专属分由对应子技能判断是否值得在该平台生产。
5. Select an editorial angle
- 选择与账号定位和内容支柱最相关、对受众最有实际价值、且能提供原创解释的候选。
- 同等条件下优先来源更强、收藏/分享和主页访问潜力更高、能形成稳定栏目承诺的候选；高阅读量但定位弱或原创增量不足的内容降级。
- 明确内容增量：背景解释、概念拆解、实践建议、不同观点比较或基于证据的个人判断。
- 不将翻译、改写标题或拼接摘要冒充原创价值。
- 把素材可支持的结论与作者自己的推断分开表述。
- 优先选择能让陌生用户在首句理解“发生了什么、为什么重要、我能得到什么”的角度；每帖只解决一个问题。
- 为每个平台版本设计平台匹配的互动入口和关注/收藏/完播理由：入口应是具体问题、取舍、可验证判断或平台专属行动；理由应体现账号持续提供的栏目、视角或方法，而不是泛泛求关注。
6. Delegate platform selection and adaptation
按目标平台读取对应子技能，只生成目标平台对应的版本：
- X / Twitter：读取 x
- 小红书：读取 xiaohongshu
- 抖音：读取 douyin
总控层先传递运行上下文让平台子技能生成发现策略，再传递已核验候选和证据卡；平台子技能负责平台专属筛选、结构、媒体、平台规则和平台发布交互。不得把“平台适配”缩减为对同一候选做机械改写。
- 围绕同一运营目标重写发现路径、候选标准、结构、节奏、信息密度和行动引导，不机械复制同一候选或同一正文。
- X 的
scheduled_run按目标策略调用x；有效unattended配置授权其直接完成一次发现、改编和发布，不得再次要求人工确认。x-api不是x的前置依赖，只有用户或配置明确选择 API 适配器时才调用。不得因 API 未启用而把有效的x无人值守运行拦截。 - 先应用账号级定位，再应用目标平台引用的风格配置；平台级风格优先于账号通用风格。
- 保留来源链接、作者归属和必要引用在证据卡、审计记录和状态文件中；公开文案是否放链接由平台子技能决定。抖音默认不把外部来源链接、下载链接或“原视频：平台名”写入标题、正文、话题或置顶评论；直接引文只使用支持论点所需的最短片段。
- 不捏造数据、引语、体验、人物反应或画面。无法确认的素材位置使用明确占位符。
- 若精确字数、视频时长、链接或商业内容规则会影响交付，先查阅平台当前官方规则。
- 封面、配图、字幕、配音或镜头仅提供可执行方案；除非用户明确要求，不自动生成媒体资产。
- 若用户要求“翻译后转发/引用”，优先使用平台的引用/转发能力保留原作者归属和原帖媒体；只在用户明确要求且素材版权、来源和上传方式都可核实时重新上传。翻译不等于原创增量，必须补充事实边界或简短解释。
7. Apply the publishing gate
先区分“创建/更新常驻调度”和“执行一次已经被调用的任务”。默认使用人工确认模式并停止在草稿和发布准备阶段；只有用户明确要求建立定时任务时，才创建或更新常驻调度。配置中的 schedule 仅为兼容旧文档的描述，不触发创建调度，也不阻断已触发运行。
每次运行先标记执行上下文：
interactive_run：用户当前直接发起的一次运营请求。scheduled_run：已有调度器、自动化任务或外部调用器触发的一次运行。schedule_setup：创建或更新常驻调度的管理操作。
自动化任务的调用提示必须同时写明：这是 scheduled_run、要读取指定账号的当前 media-ops 配置、当配置组合为有效 unattended 时无需逐条人工确认，以及仍需执行哪些内容和安全硬门禁。仅写“执行 x”不足以覆盖总控门禁，不能据此恢复旧的全局人工审核默认值。
scheduled_run 不得再次要求人工确认。对 interactive_run，如果用户明确要求按当前无人值守配置执行一次，也按该配置执行；只有 schedule_setup 仍需要用户明确要求。不要把“需要用户明确创建常驻调度”误用为“每次运行前需要人工确认”。
不要读取、填写或保存密码、Cookie、令牌和验证码。可以复用用户已建立的受控登录会话。
只接受以下发布模式：
publishingMode: reviewed：要求humanApprovalRequired: true且autoPublish: false。用户明确授权具体账号和完整内容后，可以完成单次发布。publishingMode: unattended：要求humanApprovalRequired: false、autoPublish: true、selectLimit: 1、maxPublishedPerRun: 1与有效scheduledTransport；不要求schedule、最小间隔或每日上限。配置校验通过后，scheduled_run以及用户明确要求按该配置执行的interactive_run可以直接进入发现、改编和发布，不再增加业务层逐条确认；仍必须遵守所选执行通道的运行时安全策略。
门禁结果必须按实际原因返回，不得笼统返回“未满足人工确认门禁”：
- 无人值守配置有效但没有合格候选：返回“本轮跳过：没有候选达到 minScore/内容门禁”，并说明具体门禁。
- 无人值守配置字段组合无效：返回“本轮跳过：无人值守配置无效”，列出字段路径和期望值。
reviewed模式尚未获得具体内容授权：返回“本轮暂停：人工审核模式需要确认”，不得开始最终发布动作。- 登录账号、来源、版权、事实或重复检查失败：返回对应的具体失败原因；不得伪装成人工确认失败。
无人值守运行必须执行以下硬门禁：
- 实际登录账号必须与配置中的平台 handle 一致；不一致时停止。
- 没有候选达到
minScore时跳过，不为满足频率降低阈值。 - 关键事实、来源链接、版权归属或商业披露存在缺口时跳过。
- 高影响、争议性或无法区分事实与传闻的内容不自动发布。
- 发布前检查近期账号时间线，避免重复事件、近似正文和重复链接。
- 发布后记录可见绝对指标和归一化指标，按内容支柱、格式、作者来源和互动入口复盘；用单变量实验调整首句、引用/原创、媒体、讨论问题和发布时间，不把单条爆文当作稳定规律。
- 每次运行最多发布 1 条；发布成功信号不明确时不重试。
- 对顺序下载任务，运行前读取并校验游标/已发布清单；来源 URL、视频 ID、规范化标题和作者+作品组合都必须参与去重。只在发布结果明确且状态写入成功后推进游标并清理本次临时文件；任何不确定状态都保留候选和媒体，不盲目重试。
- 外部下载必须通过页面可见的下载/备用地址控件完成；下载失败时按平台子技能规定刷新、重解析并交替恢复，不能单次失败即放弃，也不能把页面上的签名直链、媒体预览页或旧下载目录文件当作已下载素材。平台子技能必须完成音视频轨和可播放性验收后才能上传。
- 若配置了外部运营文档，成功、跳过、失败和待确认结果都要写入对应的运行记录；成功发布还要同步更新队列和已发布清单。来源链接可写入内部文档，但仍不得违反平台子技能的公开文案规则。
人工确认模式发布前要求核对：
- 事实与引用可回溯；
- 标题和钩子没有超出证据；
- 观点符合账号定位；
- 版权、隐私、商业披露和平台风险可接受；
- 每个平台版本确实针对该平台重写；
- 链接、标签、画面和口播占位符已补全。
人工确认模式下，在动作发生前说明目标平台、账号和将要发布的完整内容。只有用户对这些具体信息作出明确授权后，才点击最终发布或发送控件；不得把早期的宽泛授权解释为对后续不同内容的持续授权。无人值守模式不走这条逐条确认门禁，但仍必须执行前述事实、版权、账号、重复、限额和成功核验门禁。
使用已登录浏览器发布时，按以下低自由度顺序执行：
- 解析并锁定目标
platformAccountRef、browserProfileRef和scheduledTransport；确认执行器与配置通道一致，完成 Profile 路由后，核对当前登录身份与配置中的平台 handle 一致，再打开目标原帖或发布入口。 - 创建草稿后重新读取页面状态，确认正文、引用对象、媒体、受众和发布按钮均正确；交互控件优先用精确可访问名称定位，并先核对数量与可用状态。若编辑器追加文本而非替换，必须全选后重填并复读最终内容；抖音公开字段默认不得出现外部链接。
- 最终发布控件只点击一次。等待平台明确的成功提示、帖子 URL 或账号时间线新内容；出现超时或错误时不得盲目重试。
- 发布成功后保留已发布页面或结果页供用户复核；若没有可直接取得的帖子 URL，至少报告成功提示和目标账号。
平台专属发布前必须再次确认目标平台、账号身份、媒体/引用对象和最终控件；不得因为“配图”要求而重复上传同一官方媒体。
8. Clean up browser workspaces
任务收尾必须按“结果确认 → 外部系统回写 → 浏览器清理”的顺序执行：
- 先确认发布成功、审核中、明确跳过或明确失败的最终状态，再写入
docsRoot下的运行记录、队列/已发布清单和本地机器状态；回写失败时不得关闭仍需要核对或恢复的页面。 - 运行开始时记录本次创建的浏览器 Tab；成功回写后关闭本次运行创建的来源页、搜索页、下载页、编辑器页和结果页等临时页面，避免历史任务不断累积。
- 不关闭用户在任务开始前已经打开的页面，不关闭未完成草稿、上传/下载中页面、验证码/登录交接页或用户明确要求保留的交付页面。结果不明确时保留必要的结果页并标记为
handoff，不要靠关页掩盖不确定状态。 - 使用浏览器连接支持的 Tab 清理/finalize 能力时，将清理作为本轮最后一次浏览器操作；清理完成后不再继续点击、读取或导航。若只支持电脑操作，按同一保留规则关闭明确属于本次运行的临时窗口或 Tab。
- 在运行记录中写入清理结果：已关闭的运行 Tab 数量、保留的交接/交付页面及未能关闭的原因。不得为了“清空浏览器”而批量关闭无法确认归属的现有页面。
抖音的 operation.allowDownload 默认值为 false。media-ops 将该值传给 douyin；平台子技能负责在最终发布前重新读取“允许下载”控件并确认其处于关闭/不允许下载状态。控件状态不明或仍允许下载时，必须停止，不得因无人值守配置而发布。
9. Hand off feedback
发布、跳过、失败和不确定结果完成记录后，调用 media-loop 进行账号健康与运营效果复盘。传递平台、账号、内容支柱、格式、来源、发布时间、可见指标、发布状态和本轮策略版本；不得把凭证或隐私数据传给反馈技能。
media-loop 返回的 strategyOverrides 只作为下一轮运行的临时覆盖，除非用户明确要求修改常驻配置。media-ops 不自行修改策略、不把单条内容表现当作稳定规律，也不因反馈建议绕过事实、版权、安全、去重、限额和发布成功核验。
publish_unconfirmed 永远按不确定状态处理：不得因为 retry-on-failure 或定时器下一次触发而自动重发。只有平台明确显示提交失败，且策略明确允许重试时，才可以重试；成功页、审核中或结果冲突都先写回并暂停该 contentId + targetId。
9.1 Recover an empty ready queue
空队列恢复前先读取 media-loop 的库存指纹和生产检查点。只有当前仍有 eligible 可恢复适配目标、上次结果为 adaptation_backlog_present、指纹未变化且没有适配写回时，才执行轻量 no-op；存在可恢复适配时先恢复适配，不重新发现来源。争议、审核中、未知、已完成、账号暂停和 disabled 目标不计入 eligible 积压；排除后 ready 为零时必须进入 ready_supply_starved 供给决策。
no-ready-unfinished-due-distribution-targets 是一次扫描结果，不一定是整轮终点。刚完成 historical_result_reconciled 且当前触发仍未获得本轮新提交时，也必须进入本节；不得把历史对账当作本轮发布额度。对配置允许内容生产的执行上下文，按以下低自由度流程处理：
- 把账号、平台、策略窗口、队列库存、候选阻塞、最近发布/审核状态和最近反馈交给
media-loop。 - 若 loop 返回
adaptationRequest，先调用media-core按最早未完成资产恢复适配，再分别调用对应平台子技能；适配积压存在时不得请求新的来源生产。 - 若 loop 返回账号暂停、结果不确定、已有足量 ready 库存或无生产请求，记录具体原因并结束；不得重试审核中目标。
- 仅当 loop 明确返回
productionRequest时，调用media-core对指定 pipeline 生产并验收。来源发现、下载、版权、去重、资源路径和游标全部属于 core 及其外部协议；ops 不自行补造候选。媒体生产不再受固定“每轮最多几次”限制，由本次外部触发、队列状态、幂等键和 stopConditions 决定是否继续推进。 - core 返回
asset_ready或适配完成后，在同一轮重新扫描 ready admission 和平台门禁；符合条件才交给平台子技能。生产出的目标不受旧计划时间阻断，保留其计划字段用于审计和排序。 - core 返回
production_blocked、adaptation_backlog_present或no_qualified_candidate时写入内容层和平台运行记录，停止；同一requestId + pipelineRef本轮不得再次调用。若返回adaptation_backlog_unchanged，先校验当前 eligible 适配积压数量必须大于0；成立时按成功的轻量 no-op 记录，禁止重新访问来源、调用 Chrome、发起生产或发布，等待队列指纹变化或适配写回。若 eligible 数量为0，该结果无效，必须重分类为ready_supply_starved并继续一次有界供给恢复。
每次外部触发可以持续推进仍有明确缺口的适配或媒体供给，不再受固定获取次数门禁；但每个请求必须遵守 contentId + targetId、requestId + pipelineRef 幂等键，遇到成功、无合格候选、来源/版权/媒体失败、锁冲突、账号健康暂停或不确定发布状态即停止。单次触发仍默认最多发布 1 条，防止一次异常重入排空队列；这不是时间或频率门禁。不得形成 ops → loop → core → ops 的无界递归。
10. Apply an authorized optimization
当用户明确要求基于 media-loop 报告实施优化时，由 media-ops 负责拆分变更，不把所有调整写入同一层：
- 账号定位、发布频率、阈值和平台 operation：写入
<AGENT_HOME>/local-config/media-ops/config.yaml； - 平台通用的文案、候选、媒体验收和发布规则：写入对应平台子技能或其 references；
- 实际自动化触发频率和提示词：检查并更新对应的本机自动化定义；
media-loop只保留诊断、实验假设、结果和下一次复盘条件，不直接替代执行器改写平台内容。
实施前必须核对变更对象与账号边界，实施后验证配置、自动化定义和运行目录一致。实际触发频率以外部自动化任务当前的 RRULE 为准；技能和内容配置不得写死扫描周期，也不得因为文档窗口与 RRULE 不同就自行创建定时器。只有用户明确要求调整频率时，才同时修改策略配置与实际定时器；只改其中一处会造成“配置看似已变、实际仍按旧频率运行”。每次优化只改变报告支持的主要变量，并记录旧值、新值、生效时间、预期指标和回滚条件。
Deliver the editorial package
按以下顺序输出，省略与任务无关的部分：
- 运行上下文：账号、定位、平台身份、风格、数据源组、策略、时间窗口和本次覆盖项。
- 候选池：候选主题、原始来源、核验状态、总分、建议和淘汰理由。
- 证据卡：入选主题的关键事实、来源链接、引用位置、事实/推断边界和风险。
- 平台草稿：每个平台独立成节，包含成稿与必要的媒体制作说明。
- 编辑说明：内容增量、平台化差异、仍待确认事项。
- 发布检查单：逐项列出需要用户确认或补充的内容。
- 发布结果：仅在执行发布时提供平台、账号、成功信号和帖子链接；失败或不确定时说明停留状态。
在来源不足时，交付“待核验候选清单”和下一步取证建议，不生成貌似完整的发布稿。