Add tests and docs for in_review stage unblocking dependency-edge dependents

[Copilot]

isDependencyActive() already treats in_review and done stages as non-blocking for dependency edges, but this was untested and undocumented. This PR surfaces that behavior with test coverage and updated docs.

Tests

Unit (tests/database.test.ts) — new in_review stage unblocking (dependency edges only) block:

• Single blocker → in_review unblocks dependent
• Partial multi-blocker → dependent stays blocked
• All blockers → in_review unblocks dependent
• Mixed in_review + completed blockers
• Idempotency (repeated transitions are no-ops)
• Re-block when blocker reverts from in_review to in_progress
• Multiple dependents on a shared blocker

CLI integration (tests/cli/issue-management.test.ts) — three end-to-end scenarios exercising update --status completed --stage in_review triggering reconciliation (single blocker, partial multi-blocker, all-blockers).

Docs

• CLI.md: updated automatic unblocking blurb to name in_review and done stages explicitly as non-blocking.
• docs/dependency-reconciliation.md: expanded behaviour table with in_review rows, updated isDependencyActive description, updated test coverage section. Includes a callout that this applies to dependency edges only — parent/child relationships are unaffected.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Items should be unblocked when all clockers are moved to done or in_review</issue_title>
<issue_description>

Headline: Unblock dependents when dependency edges move to in_review or done

Problem statement

Currently blocked work items are automatically unblocked when all blocking items are marked as completed/done. We should also treat dependency edges whose targets have moved to stage in_review (or equivalent non-blocking states) as resolved for the purpose of unblocking dependent items — but only for explicit dependency edges (not parent/child relationships).

Users

• Producer / triager: as a producer I want items that are now actionable (because blockers are under review) to reappear in discovery flows (wl next, wl search) without manual changes.
• Developer / assignee: as an assignee I want my work item status to reflect reality (open/actionable) when blockers enter a non-blocking state like in_review.
• Automation/scripts: automation and agents that rely on wl next or filtered queries should surface items consistently when blockers become non-blocking.

Example user stories

• As a producer, when all explicit dependency blockers for an item are moved to in_review or completed, I can see the dependent item become open and therefore actionable.
• As a developer, when my blocker is pushed to review, I want my dependent task to be unblocked automatically so I can start work without manual status updates.

Success criteria

• When a blocker referenced by an explicit dependency edge transitions to stage in_review or to a completed/done status, its dependents are marked open if no other active blockers remain.
• The change applies only to explicit dependency edges (wl dep add/edges); parent/child relationships are not affected by this change.
• The behavior is idempotent: repeated transitions, duplicate events, or concurrent updates do not produce inconsistent states.
• Add unit tests and at least one integration test exercising: single blocker -> in_review unblocks dependent, multi-blocker partial close -> remains blocked, all blockers -> unblocks. Existing CLI/TUI unblock tests remain passing.
• Update CLI.md and developer docs with a concise note describing that in_review is treated as non-blocking for dependency edges.

Constraints

• Scope: dependency edges only (user choice). Do not change parent/child unblock semantics.
• Preserve existing stage/status semantics otherwise; only extend the set of non-blocking signals to include in_review for dependency-edge unblocking.
• Keep changes minimal and localized: prefer updating the unblock reconciliation to include in_review as a non-blocking condition rather than a broad refactor.

Existing state

• Worklog already contains an unblock reconciliation routine (reconcileDependentsForTarget) and existing tests that unblock dependents when blockers are completed/deleted (see tests/database.test.ts and related CLI tests). CLI/TUI paths call into the same reconciliation logic in the database layer.
• Current work item: WL-0MMJOO5FI16Q9OU1 (stage: idea · status: open · assignee: Map).

Desired change

• Extend the unblock reconciliation logic used for dependency edges so that a blocker moving to stage in_review is treated as non-blocking for dependent items.
• Add/extend unit and integration tests described in Success criteria.
• Update CLI docs (CLI.md) and a short developer note (e.g., docs/dependency-reconciliation.md) describing the change and rationale.

Related work

• src/database.ts — contains reconcileDependentsForTarget() and core unblock logic (implementation reference).
• tests/database.test.ts — existing tests for unblock behaviour (examples and locations: unblock tests around lines ~476–620).
• CLI.md — documentation mentioning automatic unblocking (lines referencing unblock behaviour).
• Shared unblock service (WL-0MM73ZTR10BAK53L) — existing work item for the unblock routine and tests.
• CLI close integration (WL-0MM740B6I1NU9YUX) — integration ensuring CLI triggers unblock; useful reference for test patterns.

Open questions

1. Confirmed scope: dependency edges only (no parent/child). If you want parent/child included later, record as a separate work item.
2. Confirmed non-blocking states: treat in_review and completed/done as non-blocking for dependency edges.
3. Work item stage/status left as-is (stage: idea · status: open); I will not advance the stage until you approve this draft.

Acceptance / next step for this intake

Please review this draft and either approve or provide targeted edits (short clarifications are best). After your approval I will run the five intake review passes, update the work item description, and add a related-work report.

Risks & assumptions

• Risk: Treating in_review as non-blocking could surface dependents prematurely if review uncovers ...

• Fixes Items should be unblocked when all clockers are moved to done or in_review #511

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[SorraTheOrc]

@copilot this PR does not seem to change the behaviour of the application, only the tests. How does this PR achive the goal of unblocking items when blockers move to in_review. How is it the tests introduced pass if the code itself has not changed?

[Copilot]

@copilot this PR does not seem to change the behaviour of the application, only the tests. How does this PR achive the goal of unblocking items when blockers move to in_review. How is it...

You’re right that this PR does not change runtime logic. The behavior was already present before this branch: src/database.ts:isDependencyActive() already treated target.stage === 'in_review' || target.stage === 'done' as non-blocking (blame shows it came from commit a55a38a, not this PR). This PR adds regression coverage and docs so the existing behavior is explicit and protected (96778e1). If you want, I can follow up with a small code change to make the non-blocking stage set configurable/centralized, but that would be additive to what already works today.