issue-link.sh silently downgrades unsupported relations (blocks -> relates_to) #18

New issue

jbr870 · 2026-08-11T14:57:24Z

jbr870 commented

2026-08-11 14:57:24 +00:00

Observed failure

issue-link.sh silently downgrades relations the forge does not natively support:

blocks became relates_to on GitLab CE — 4 times in one run (verity #113), with nothing on the
record saying the relation shipped weaker than requested.
An unsupported sibling relation was pre-swallowed (verity #164).

The link exists, so the caller believes it got what it asked for. The record says something weaker than
the caller intended, and nobody can tell the difference later.

The decision to make

Two coherent options, and the point is to pick one deliberately:

Warn-and-degrade, loudly — current behaviour plus an explicit record of the downgrade (a note on
the link, or a warning the caller must surface). Keeps the call working everywhere.
Capability-manifest entry per relation type — the adapter declares which relations it supports
natively, and an unsupported relation is a refusal rather than a quiet substitution. Consistent with
how the contract handles other capability gaps (polyfill / native / unsupported).

Option 2 matches the contract's existing shape; option 1 is cheaper and never blocks a run. Either is
defensible — silent downgrade is not, because it makes the record assert a relation nobody chose.

Source: dogfood retrospective 2026-08-07 (F2/F5), deferred backlog.

## Observed failure `issue-link.sh` **silently downgrades** relations the forge does not natively support: - `blocks` became `relates_to` on GitLab CE — 4 times in one run (verity #113), with nothing on the record saying the relation shipped weaker than requested. - An unsupported `sibling` relation was **pre-swallowed** (verity #164). The link exists, so the caller believes it got what it asked for. The record says something weaker than the caller intended, and nobody can tell the difference later. ## The decision to make Two coherent options, and the point is to pick one deliberately: 1. **Warn-and-degrade, loudly** — current behaviour plus an explicit record of the downgrade (a note on the link, or a warning the caller must surface). Keeps the call working everywhere. 2. **Capability-manifest entry per relation type** — the adapter declares which relations it supports natively, and an unsupported relation is a *refusal* rather than a quiet substitution. Consistent with how the contract handles other capability gaps (`polyfill` / `native` / unsupported). Option 2 matches the contract's existing shape; option 1 is cheaper and never blocks a run. Either is defensible — **silent downgrade is not**, because it makes the record assert a relation nobody chose. *Source: dogfood retrospective 2026-08-07 (F2/F5), deferred backlog.*

jbr870 referenced this issue

2026-08-25 14:59:12 +00:00

Auditing the other primitive dispatches for correctness beyond existence #103

Sign in to join this conversation.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

jbr870/devwork-skills#18

Rows
Columns