v0.2.0-rc.3

Add lifecycle comments and reopen closed issues (#52)

* Post lifecycle comments when creating or closing issues (#52)

When Dependicus creates or closes a Linear or GitHub issue, it now posts
a comment explaining why. This gives issue subscribers immediate context
about the lifecycle event without having to re-read the full description
or guess why the state changed.

On creation, the comment includes the policy type, update type, SLA
window, and days overdue. Plugins and config can contribute additional
context via a new `commentSections` field on the issue spec (same shape
as `descriptionSections`, but routed to the lifecycle comment instead of
the issue body). Multiple plugins' sections are concatenated, following
the established merge pattern.

On closure, the comment simply states the dependency is now compliant.
Since the spec returns `undefined` for compliant deps, close comments
are purely auto-generated.

`LinearService.createIssue` now returns `{ id, identifier }` instead of
just the identifier string, since posting a comment on a newly created
issue requires the UUID that was previously discarded.

Like a well-meaning goose honking at every passerby, Dependicus will now
loudly announce exactly why it showed up and why it's leaving.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Reopen closed issues instead of creating duplicates

When Dependicus is about to create a new issue, it now checks for a
closed issue with the exact same title first. If one exists, it reopens
and updates it rather than creating a duplicate. This handles the
spurious-close-then-redetect scenario without accumulating duplicate
issues over time.

The lookup uses a targeted API call per dependency (Linear title filter,
GitHub search API) rather than paginating through all closed issues up
front. Normal runs with no reopens needed make zero extra API calls.

Also adds a live Linear API test script (`mise run test:find-closed-issue`)
that validates the title filter behavior against real data. Even a goose
knows not to build a new nest when the old one is right there.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Remove creation comments from issue lifecycle

The ticket itself is the notification — a comment saying "I made this
ticket" is redundant. Close and reopen comments still carry useful
context about why the state changed, so those stay.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Clean up from self-review

Fix stale JSDoc ("when the issue is created" -> "e.g., reopen") on the
commentSections schema field. Rename IssueCreatedCommentParams to
IssueReopenedCommentParams since the creation comment no longer exists.
Remove the empty dry-run no-op in LinearService.findClosedIssue. Delete
the live test script and its mise task.

Add a `reopened` counter to ReconciliationResult so callers can
distinguish reopened issues from newly created ones. The summary log
line now shows the breakdown.

Add unit tests for findClosedIssue and reopenIssue on both
LinearService and GitHubIssueService.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Fix stale JSDoc on OutdatedDependency.commentSections

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Enrich lifecycle comments with reasons and prevent flapping

Close comments now include version info ("now at version X.Y.Z") or
note when a policy change caused the closure. Reopen comments include
the installed and latest versions.

The reconciler now refuses to close an issue when the dependency was not
reported by any provider in the current run. Previously, a provider
timeout or failure would cause the dep to vanish from the input,
triggering a spurious close — then the next run would see it as outdated
again and reopen. This close-reopen flap repeats indefinitely. The fix:
if the dep is absent from the input entirely, skip the close and log a
warning. The safe failure mode is an issue that stays open when it maybe
shouldn't, rather than one that bounces every run.

Group issues still close normally (their membership is harder to verify
and they're less prone to flapping).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Fix group flapping prevention in close loop

The close loop's flapping guard used dependenciesByGroup to decide
whether a group close was safe, but that map only contains outdated
deps. When a group's deps are all compliant (version == latestVersion),
they're filtered before the spec callback runs, so the map never
learns about them. This blocked legitimate group closes.

Build a reportedGroups set that probes the spec callback for compliant
deps to discover their group membership. The close loop now checks
reportedGroups instead of dependenciesByGroup, correctly distinguishing
"group is compliant" from "group's deps are absent due to provider
failure." Also added the missing group flapping guard to the GitHub
reconciler, which only had the individual dep guard.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Fix reportedDeps for ecosystem-qualified keys and add comment builder tests

reportedDeps was keyed by dep.name alone, but issue.dependencyName is
ecosystem-qualified (e.g. "npm::braintrust") for new-format titles. This
caused the flapping guard to block ALL closes for ecosystem-qualified
issues. Store each dep under both its bare name and its qualified key.

Also add unit tests for buildIssueClosedComment and
buildIssueReopenedComment in both Linear and GitHub issueDescriptions
test files, addressing bugbot feedback.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Changelog

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>