Problem
When a relationship changes via spectrack issue link <source> ..., the provider applies the change on the provider side — where a relationship is inherently bidirectional (a Jira issue link is a single object surfaced from both issues; a GitHub sub-issue/dependency flips the other side's child/blocking list) — but then refreshes the cache projection for the source issue only.
The target issue(s) on the other side of the relation keep a stale relation.md until separately re-fetched.
Expected
Changing a relationship should refresh relation.md for every issue involved in the relation, not just the source.
Scope / decisions
- Applies to both Jira and GitHub providers (kept at parity).
- Only refresh targets that are already tracked in the local cache; never materialize an untracked issue.
- Remote-link targets (external URLs) have no local projection and are skipped.
- Target refresh is best-effort: the provider write already succeeded for both sides, so a failed target fetch is reported rather than rolling back the applied relationship.
Problem
When a relationship changes via
spectrack issue link <source> ..., the provider applies the change on the provider side — where a relationship is inherently bidirectional (a Jira issue link is a single object surfaced from both issues; a GitHub sub-issue/dependency flips the other side's child/blocking list) — but then refreshes the cache projection for the source issue only.The target issue(s) on the other side of the relation keep a stale
relation.mduntil separately re-fetched.Expected
Changing a relationship should refresh
relation.mdfor every issue involved in the relation, not just the source.Scope / decisions