Skip to content

[Feature] Let skill authors track review progress and resubmission history #620

Description

@XiaoSeS

Problem

Skill authors do not have a durable place to track the outcome of their review submissions. The current my-submissions view only returns pending tasks, so an item disappears after approval or rejection. Notifications help at the moment of a decision, but they do not provide a searchable progress view or preserve the sequence of review comments across repeated submissions.

The current same-version resubmission path also deletes all review tasks for the replaceable version. That makes an accurate attempt history impossible to reconstruct and removes useful governance context after an author addresses reviewer feedback and resubmits.

Proposed Solution

Add an author-facing review progress workflow as one end-to-end slice:

  • Provide a paginated “Review Progress” page that groups entries by skill version and shows the latest status, submission/review times, latest comment, and attempt count.
  • Support status filtering, skill/namespace search, and current-status summary counts without loading every historical task into memory.
  • Let an author expand a row or open a detail view to see every submission attempt, numbered in submission order and displayed newest first.
  • Preserve settled review tasks when the same version is resubmitted; only an obsolete still-pending task should be withdrawn.
  • Apply the existing review visibility rules so only the submitter and authorized reviewers can read the history.
  • Link the workflow from the author dashboard and provide a resubmit action for rejected entries.
  • Add repository/query indexes and backend, frontend, authorization, and regression tests for multiple attempts, filtering, pagination, and empty states.

This should complement, not replace, review notifications. It is distinct from #205, which was resolved by notifying authors about review decisions.

Alternatives Considered

  • Rely only on notifications: notifications are transient and do not provide a complete audit trail or multi-attempt context.
  • Keep showing only pending submissions: authors still cannot inspect completed or rejected reviews after the task leaves the queue.
  • Return every review task as a flat list: repeated attempts become noisy, current state is unclear, and pagination can split attempts for the same version unpredictably.

Impact

This changes review-task retention semantics for same-version resubmissions and adds read queries over historical review data. It requires authorization checks, a supporting database index, localized UI states, and care around pagination/query performance. Existing review approval and rejection behavior should remain unchanged.

Contract Or SDK Impact

Additive OpenAPI changes are expected: an endpoint for the current user's grouped review progress and an endpoint for authorized per-task/per-version history. Generated web API types must be regenerated. No existing endpoint or CLI protocol needs to change.

Metadata

Metadata

Assignees

No one assigned

    Labels

    effort/l大改动或高风险改动,需要 maintainer 负责 / Large or risky change requiring maintainer ownership.enhancementNew feature or requestpriority/p1高优先级 / High priority triage bucket.risk/high涉及安全、鉴权、迁移或公共契约 / Touches security, auth, migrations, or public contracts.triage/core交由 core maintainer 结合 AI 协同处理 / Issue should be handled by a core maintainer with AI support.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions