mcpField
M
manage-report-lifecycle

manage-report-lifecycle

github.com/bhagyamudgal文档处理298 次安装3 天前更新
代码仓库

关于 manage-report-lifecycle

manage-report-lifecycle 用于在保留来源和前序报告的同时,维护一份权威托管报告。它协调清点、内容暂存、变更预检、发布回读及证据核验。

主要功能

  1. 01清点报告及来源条目
  2. 02暂存规范报告与前序报告内容
  3. 03要求使用持久化生命周期记录
  4. 04发布变更前执行预检
  5. 05核验链接、权威状态与证据

适用场景

  1. 01从现有候选报告中确定规范报告
  2. 02用替代标记更新可写入的前序报告
  3. 03在发布和核验中追踪来源发现

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/bhagyamudgal/skills --skill manage-report-lifecycle

安装后在 Claude Code 中输入/manage-report-lifecycle确认已加载。

附带文件agents/openai.yaml

详细介绍

管理报告生命周期

建立一个唯一权威的托管报告,同时保留每个源项目及其前身。此技能负责协调此处的生命周期语义、通过 preflight-mutations 进行的共享状态授权,以及通过 done 进行的最终验收。

1. 清点报告集合

运行一条权威的主机或工作区发现查询,范围需足够广,以查找标题、稳定 ID、源 URL 或主题与该报告匹配的所有托管分析文档。记录确切查询、每个匹配项的稳定主机 ID 和当前保护措施,并将每项归类为 source、canonical-candidate 或 unrelated,同时说明理由。

获取每个源和规范候选项的渲染内容及稳定 URL。对每项记录其 URL、标题、写入权限、当前权威或取代标记,以及由源所有的发现项或条目 ID 和对应的直接证据 URL。保留源工作流 ID。如果报告没有此类 ID,则分配作用域限定于文档的 ID,不得更改源内容。

在只读清点和暂存期间,将此工作记录保留为内联记录。在开始多次写入发布之前,将其持久化到用户已授权此工作流写入的现有持久化台账中。记录其稳定 URL 或路径,并要求在整个运行期间,该台账始终位于所有规范发布目标和前身发布目标之外。如果不存在此类台账,则停止并说明下一步操作是授权一个合适的现有文档。不得创建生命周期注册表。

通过条件是:已记录确切的发现查询和所有已分类的匹配项;每个源、规范候选项和源条目均且仅出现一次;已确认写入权限;并且明确记录了相互竞争的权威声明。

2. 暂存规范记录

选择一个已有的、托管且可写的规范候选对象,并确认其稳定 URL 和当前写入保护条件。如果不存在这样的对象,请停止,并将创建或选择该托管候选对象列为下一步操作。本技能不会创建第一个规范对象。

选定后,将每个发现的匹配项重新归类为 canonical、writable-predecessor、unwritable-predecessor 或 unrelated,并为每个无关匹配项说明理由。任何自称当前权威来源的非规范匹配项都必须归入某个前任类别,并列入生命周期记录和发布计划。

生命周期 Artifact ID 必须独立于任何托管版本。复用现有生命周期 ID,或仅分配一次,并在替换过程中保留该 ID;同时单独记录当选版本的宿主对象 ID 和 URL。

在规范报告中暂存本节:

## Report lifecycle

- **Artifact ID:** <stable ID>
- **Current host object ID:** <host ID>
- **Canonical URL:** <exact URL>
- **Source reports:** <complete URL list>
- **Supersedes:** <complete predecessor ID and URL list>
- **Unwritable predecessors:** <URL and reason, or none>

对于每个可写前任,暂存其完整的已获取报告,并附上 Superseded by [<artifact ID>](<canonical URL>).。原始正文和带来源归属的证据必须逐字节保留。仅包含标记的替换内容不是有效载荷。在规范报告中记录不可写前任及其原因,不要将缺少标记视为成功。

为每个来源条目选择一种处置方式:

来源条目 ID来源证据 URL处置方式规范目标位置或理由
carried | merged | dismissed | retained-by-reference<规范条目/锚点 ID 或驳回理由>

carried 和 merged 必须指定一个现有的规范目标 ID。dismissed 必须记录理由。retained-by-reference 必须指定保留原始证据可访问性的规范锚点。仅合并真正等效的条目。将独特发现保留为不同的目标或引用,而不是复制整份来源报告。

在渲染任何发布载荷之前,完成并验证处置映射。要求其中的来源条目 ID 与清单完全一致,不得有重复行;并要求每个指定的规范目标或锚点均存在于暂存的规范记录中。

将完整的规范载荷和每个可写前任载荷分别渲染到独立且不可变的本地暂存路径,并将每个路径视为仅写入一次。将每个路径及其 SHA-256 摘要记录在生命周期账本中。绝不覆盖或重新生成已冻结的文件。字节发生变化时,必须使用新路径,并生成新的摘要、预览和预检。

通过条件是:已确认现有托管可写规范候选对象及其写入保护条件;每个发现的匹配项均已完成最终分类;每个非规范权威来源均已绑定为前任;规范载荷、包含“报告加标记”的前任载荷以及条目映射均已完整暂存,且每个来源条目都恰好分配了一种有效处置方式。

3. 预检发布计划

构建一份完整的逻辑发布计划,其中包含:

  • 完整的规范载荷及其当前写入保护;
  • 每个规范载荷和可写前序项载荷冻结后的本地路径、SHA-256 摘要及当前写入保护;
  • 产物 ID、规范 URL、来源 URL、已取代项列表和不可写前序项记录;
  • 每个来源项的处置方式及目标位置或理由;
  • 权威的渲染链接和重复状态回读计划;
  • 所有写入之间的依赖顺序。

严格按照 preflight-mutations 对不同所有权、环境、可逆性或确认域的要求,将该计划划分为一张或多张变更卡。将所有卡片一并预览。在首次写入前立即为每张卡调用 preflight-mutations,并传入准确的目标、授权、保护、恢复方案、失效项、有序条目、依赖项和回读计划。

按照预览时的依赖顺序,执行每张卡的 preflight-mutations 结果约定。将受阻或需要确认的卡片及其依赖写入保留为待处理状态。新增目标、标记或内容变更时,须将完整计划重新提交预览。仅对已失效的卡片重新预检。

门槛是:完整预览涵盖每项生命周期写入;每项写入恰好属于一张领域划分正确的卡片;且任何未经预览或违反依赖关系的写入都无法执行。

4. 发布并协调

应用已暂存的规范载荷和前序项报告加标记载荷,不要重新生成。每次写入前,立即重新计算其冻结文件的摘要,并要求其与台账和当前变更卡中的摘要一致。若不一致,则在写入前将该卡标记为失效。以原子方式将该项在持久化台账中的状态从 pending 转为 attempting,且仅当转换从预期状态成功执行时才继续。对于每张卡,遵循 preflight-mutations 的执行和部分状态约定,同时保持发布计划的依赖顺序和合并后的条目台账。每次尝试写入后,权威地回读正文和保护,然后在下一次写入前,将该项结果、回读保护和观测到的正文摘要以原子方式持久化到台账中。若台账转换不可用或存在歧义,则停止所有依赖的后续操作。仅当完整的回读正文与冻结字节一致时,才将该项标记为 landed。在记录前序项的标记写入为 landed 前,须确认其已获取的内容和归属证据仍完整,并将回读保护记录为该目标预期的写后保护。

门槛是:发布计划中的每项都有权威结果;每个已落地载荷都与其暂存内容一致;规范报告及每个可写前序项都具有通过权威回读获得的预期写后保护。

5. 验证权威性和证据

重新获取并重读渲染后的规范报告及每个前序项。检查每个规范链接、来源链接、前序项链接和证据链接。重复 Phase 1 中完全相同的发现查询,并将其稳定主机 ID 和守卫与预期集合进行比较。对已落地的目标使用 Phase 4 中权威的写入后守卫,对未更改的匹配项使用 Phase 1 守卫。预期的已落地守卫不属于漂移。缺少稳定 ID、出现新的匹配项或守卫不在预期集合内,都需要返回清单整理、暂存和预检。继续之前,获取每个意外匹配项。

完成条件:

  • 规范报告显示确切的生命周期工件 ID、当前主机对象 ID、规范 URL、完整来源 URL 和已取代项列表;
  • 每个可写的前序项都渲染规范替代标记和链接;
  • 每个不可写的前序项及原因都出现在规范报告中;
  • 每个来源项都恰好在项目映射中出现一次,并且有可访问的目标位置或已记录的驳回理由;
  • 每个必需的渲染链接都能解析;并且
  • 没有可写的竞争权威来源或重复匹配项仍将自身标记为当前权威来源。

在完成前修复并重新读取缺失的证据或链接。存在可写的竞争权威来源、必需链接失效或来源项未计入时,均不得完成。

对适用的最终文档、外部元数据和发布工作流运行 done。提供最终项目台账、渲染后的链接结果、重复状态查询、不可写的前序项,以及确切的下一步操作。

当一份托管报告可验证为规范报告、所有前序项均已标记或记录、每个来源项均已计入,且完成声明符合 done 的证据上限时,本次运行即告完成。

评论

支持 Markdown