Skip to content

Verify marketplace release candidates against fresh remote state #266

Description

@devantler

🤖 Generated by the Agentic Engineer

Problem and evidence

Release preparation and verification are merged in #249 and #253. They inspect local Git objects, so a successful assessment can still use stale tags or nominate a commit that is no longer the default-branch tip. Publishing from that assessment alone would not establish agreement with GitHub.

Proposed outcome

Add an opt-in, read-only prepublication check that combines the existing candidate verifier with fresh GitHub state. Bind the repository identity, current default branch, complete tag inventory and absent candidate release to the selected source and release commits. Reject missing, malformed, incomplete, changed or conflicting observations. Do not modify refs, the checkout, tags, releases or installed plugins.

Acceptance criteria

  • The local verifier must pass for the explicit full source and release commits.
  • The remote repository identity and current default-branch tip must match the intended repository and release commit.
  • Complete remote tag identities must agree with local tags, including annotated tags; a moved baseline, omitted page or occupied candidate tag fails.
  • The intended GitHub release must be absent; authentication, transport and malformed-response failures never mean absence.
  • Repeat the remote observation after local assessment to detect movement during the check, and label successful output assessment-only and NOT_AUTHORIZED.
  • Exercise initial and incremental candidates against real Git fixtures with an offline forge stub, prove no writes, and perform a read-only check against the real marketplace.
  • Document the limits: a snapshot cannot reserve a tag, prove review readiness, or guarantee state remains unchanged after it returns. Publication remains a separate feat(ci): cut semver releases so the marketplace has a version to pin #101 increment.

Size: M. Success is rejection of every stale/conflicting fixture while an unchanged real candidate passes without remote writes.

Part of #101.

Activity

  1. self-assigned this
    on Sep 30, 2026
  2. moved this to 🏃🏻‍♂️ In Progress in 🌊 Project Boardon Sep 30, 2026
  3. added a commit that references this issue on Sep 30, 2026
  4. devantler commented on Sep 30, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer

    Delivered in #267, merged at ac6197dcc8d0deea3ccc2cd2d4e1e886fa0a0b59 from reviewed head 4a2c1ef6f03a075381631c5e4a72761e87c0f47a.

    Post-merge verification used an isolated checkout of that exact main commit and the real GitHub repository. A freshly generated candidate bound to the merged commit returned VERIFIED with matching main and complete tag inventory and an absent proposed release. The formerly valid candidate bound to 92338259ce6f6dcf2d47babe0328fe068480e2c0 was rejected with no assessment output after main moved. No tag or release was created.

    The 39-case suite and current-head CI passed. CodeRabbit completed a substantive code review; after the documented ancillary-finding resolution, all three review providers explicitly refused the follow-up for quota. The contract-defined full local review was posted at the exact head and passed the review-verdict check before promotion and the protected, head-pinned merge.

    All acceptance criteria for the remote assessment are met. Actual release publication and consumer delivery remain tracked by #101.

  5. closed this as completedby moving to ✅ Done in 🌊 Project Boardon Sep 30, 2026
  6. moved this from 👀 In Review to ✅ Done in 🌊 Project Boardon Oct 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Fields

Priority

None yet

Start date

None yet

Target date

None yet

Effort

None yet

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions