fix(release): tolerate bounded draft-list eventual consistency

[100yenadmin]

Problem

The protected Electric release workflow can fail after successfully creating the exact-head tag, draft release, and both assets. In run #29369633801, gh release download succeeded and sha256sum --check passed, but the immediately following paginated release-list query returned zero matches for several seconds and the job exited with No draft release exists.

Evidence

• Run: https://github.com/electricsheephq/evaOS-gitnexus/actions/runs/29369633801
• Release commit: e690cabf19dea108fced6ee1a7ef17e9e623ec54
• Tag: electric/v1.6.10-electric.2 resolved to that commit.
• Draft ID: 354098134; both non-empty assets existed and downloaded successfully.
• Attempt 1 failed only at the one-shot list lookup after checksum verification.
• Rerunning failed jobs only reused the proven tag/draft/assets and published successfully; no CI, package build, or platform proof was repeated.

Likely cause

GitHub release-list eventual consistency immediately after draft creation. The workflow treats one empty list response as definitive even though the asset download endpoint already resolves the draft.

Acceptance

• Resolve the exact draft by a direct stable identifier or use a bounded retry around release discovery.
• Require exact tag, draft state, target commit, and the two non-empty expected assets before publication.
• Keep retry bounded and fail closed on duplicates, mismatched tag/head, published state, or timeout.
• Add focused policy/verifier coverage for delayed visibility.
• Preserve publish-last, protected-environment approval, and resumable failed-job behavior.
• No npm/container publication and no changes to the already published .2 release.

[evaos-code-review-bot]

evaOS issue enrichment

Issue: #126 - fix(release): tolerate bounded draft-list eventual consistency
State: open

Related issues/PRs: #29369633801.
Existing labels: P1, evidence-gate, fork-only.
Suggested labels: tests.
Suggested owners: none.

Related context

• #29369633801 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.

Agent-start packet

Problem shape: fix(release): tolerate bounded draft-list eventual consistency - ## Problem The protected Electric release workflow can fail after successfully creating the exact-head tag, draft release, and both assets. In run #29369633801, gh release download succeeded and sha256sum --check
Product fit: Implementation issue; keep product fit lightweight unless VISION.md/repo policy raises a constraint.
Implementation wedge: Prototype the candidate module behind a config flag or fixture before committing to the dependency.

Build / borrow / buy scan:

• Build: identify the smallest implementation wedge that proves the issue without broad rollout.
• Borrow: inspect same-repo prior art, repo memory, GitNexus context, and allowlisted cross-repo examples first.
• Buy/use: run capped external OSS/library/API/current-market research with citations, observed dates, and why each source matters.
• Library choice: compare maintenance, API fit, license, bundle/runtime cost, and integration proof.

Candidate sources:

• VISION.md / repo policy / repo-memory.md / GitNexus packet.
• Same-repo issues and PRs referenced by issue metadata.
• Allowlisted cross-repo GitHub examples with direct issue/PR/repo URLs.
• External OSS repositories or library/API docs with freshness dates.

Acceptance criteria:

• Preserve and execute the issue's stated acceptance criteria.
• Include source citations for any external OSS/library/current-market claims.
• Keep issue-enrichment comments sticky and idempotent.
• Keep labels, owners, reviewers, and roadmap fields suggestion-only.

Proof plan:

• Focused unit/fixture test for the changed planner behavior.
• Dry-run issue-enrichment evidence packet before live comment posting.
• Redaction check for issue body, citations, and generated markdown.
• Dependency/license/API-fit note before adding or relying on a package.

Known traps:

• Do not treat related links as proof by themselves; each source needs a reason why it matters.
• Do not scan old issue backlogs or exceed repo-level enrichment throttles.
• External research must stay capped, cited, fresh-dated, and redacted.

Non-goals:

• Do not auto-apply labels, owners, reviewers, roadmap fields, or milestones.
• Do not bulk-enrich old backlog issues from this planner output.
• Do not claim external market or OSS research was performed unless cited sources are present.

Context-source taxonomy:

• [enabled] vision_repo_policy_memory_gitnexus: Use repo vision, policy, memory, and GitNexus first before external research.
• [enabled] same_repo_issues_prs: Issue metadata contains same-repo references.
• [enabled] allowlisted_cross_repo_github: Triggered by issue class; keep to configured allowlist and source caps.
• [enabled] external_oss_examples: Use for build/borrow/buy precedent with citations and observed dates.
• [enabled] library_api_docs: Use when implementation may depend on a module, SDK, API, or framework choice.
• [deferred] current_market_examples: Deferred for implementation-only issues.
• [enabled] internal_mcp_docs: Use internal docs/MCP context when available; missing context is degraded, not blocking.

Validation suggestions

• Confirm owner, acceptance criteria, and validation evidence before implementation.

Triage gaps

• Owner or reviewer signal not detected in issue body.

No labels, owners, reviewers, or roadmap fields were changed by this bot.