Ideation pipeline regenerated a duplicate post (slug ergo-decedo) that collides on permalink and can never pass CI #367
Labels
No labels
Agent
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No assignees
1 participant
Notifications
Total time spent: 42 seconds
Due date
igor
42 seconds
No due date set.
Dependencies
No dependencies set
Reference
joshtronic/igor#367
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Diagnosis
The ideation pipeline produced
2026-07-08-ergo-decedo.md— same slug, title, and thesis as2026-07-07-ergo-decedo.md, which already merged as PR #306. The two files write the same Eleventy permalink (posts/ergo-decedo/index.html), so PR #307's CI can never go green. The dedup guards that ran that tick (shipped digest ... (dedup signal),source filter: 33 already-cited source(s) excluded) did not catch a same-slug/same-argument regeneration on consecutive days. The harness handled it correctly (REQUEST_CHANGES → rework produced no commits → escalated to human), but the wasted PR + rework round + escalation are all downstream of an ideation-side dedup gap.Evidence
Fixed looks like
The ideation dedup step rejects a candidate whose slug (or near-duplicate thesis/title) matches an already-shipped post before drafting/PR creation, so it re-rolls instead of opening a PR that is structurally un-mergeable. Bonus: auto-close/abandon a PR whose only diff is a duplicate-permalink file rather than routing it through a human escalation.
service: agent.service
severity: medium
window: 2026-07-08 00:00-01:00 (filed by the hourly logwatch pass)
Closes #NNkeyword when a PR resolves an issue #372