adr check: C11 drops the host from an issue URL and reads the link on the record's own forge

hexajon commented

2026-09-24 19:36:41 +00:00

Owner

What happens

madtea adr check rule C11 reads every issue link under ## More Information. For a full URL, issueURLRE in internal/service/adr/adr.go captures only the owner, the repo, and the number. parseIssueLinks then stores owner/repo#n, and fetchIssue reads that issue on the forge of the checkout. The host in the URL is lost.

So a record whose repo is on one forge, and that links an issue on another forge, fails C11 on that link. For example, a record on forge-a.example whose More Information links https://forge-b.example/acme/tool/issues/528 fails with:

C11: could not read acme/tool#528: API error 404: not found

I hit this on a record that links two madtea issues from a repo on a different forge. When the same owner/repo and number also exist on the record's own forge, C11 reads that other issue instead, and passes or fails on the wrong issue's state.

Expected

C11 reads a linked issue on the host in its URL. When madtea has no credentials for that host, C11 says that it cannot check a link on another forge, and names the link. It never reads a different issue on the record's own forge.

Acceptance criteria

A test record links an issue URL on a second host. C11 reads that host, or reports the link as unchecked on another forge. It never queries the record's own forge for that link.
A test where the same owner/repo#n exists on the record's own forge proves that C11 does not read it for a URL on another host.
The C11 help text in internal/mcp/tools_help.go says how a link on another forge is handled.

## What happens `madtea adr check` rule C11 reads every issue link under `## More Information`. For a full URL, `issueURLRE` in `internal/service/adr/adr.go` captures only the owner, the repo, and the number. `parseIssueLinks` then stores `owner/repo#n`, and `fetchIssue` reads that issue on the forge of the checkout. The host in the URL is lost. So a record whose repo is on one forge, and that links an issue on another forge, fails C11 on that link. For example, a record on `forge-a.example` whose More Information links `https://forge-b.example/acme/tool/issues/528` fails with: ``` C11: could not read acme/tool#528: API error 404: not found ``` I hit this on a record that links two madtea issues from a repo on a different forge. When the same `owner/repo` and number also exist on the record's own forge, C11 reads that other issue instead, and passes or fails on the wrong issue's state. ## Expected C11 reads a linked issue on the host in its URL. When madtea has no credentials for that host, C11 says that it cannot check a link on another forge, and names the link. It never reads a different issue on the record's own forge. ## Acceptance criteria - [ ] A test record links an issue URL on a second host. C11 reads that host, or reports the link as unchecked on another forge. It never queries the record's own forge for that link. - [ ] A test where the same `owner/repo#n` exists on the record's own forge proves that C11 does not read it for a URL on another host. - [ ] The C11 help text in `internal/mcp/tools_help.go` says how a link on another forge is handled.

hexajon referenced this issue

2026-09-24 19:37:54 +00:00

adr check: say what is wrong and how to fix it, in plain words, with no rule codes #492

hexajon commented

2026-09-24 19:48:21 +00:00

Author

Owner

The title and body name the check by its rule code, C11. The plain name is the linked-issues check (#492). Retitle this issue to: adr check: a link to an issue on another forge is read on the record's own forge, and read C11 in the body as the linked-issues check. The one exception is the quoted error output, which shows what madtea prints today.

The title and body name the check by its rule code, `C11`. The plain name is the linked-issues check (#492). Retitle this issue to: `adr check: a link to an issue on another forge is read on the record's own forge`, and read `C11` in the body as the linked-issues check. The one exception is the quoted error output, which shows what madtea prints today.

hexajon commented

2026-09-26 16:54:06 +00:00

Author

Owner

After #634, adr check reads only the issue links in a record's Decision issues: list. Decided: when one of those links points to a forge that madtea has no login for, the check fails. The message names the link. It says to log in to that forge, or names the flag that skips the forge checks.

After #634, `adr check` reads only the issue links in a record's `Decision issues:` list. Decided: when one of those links points to a forge that madtea has no login for, the check fails. The message names the link. It says to log in to that forge, or names the flag that skips the forge checks.

hexajon referenced this issue

2026-09-28 18:16:43 +00:00

decision: move the ADR tooling into its own Go module, or keep it in madtea and improve it? #643

hexajon referenced this issue

2026-09-29 19:31:31 +00:00

epic: v0.20.0 - breaking: clearer ADR tooling and the write guard on every surface #675

hexajon added a new dependency

2026-09-29 19:33:15 +00:00

#675 epic: v0.20.0 - breaking: clearer ADR tooling and the write guard on every surface

hexajon added a new dependency

2026-09-29 19:36:03 +00:00

#674 epic: run forge tests against throwaway Forgejo and Gitea servers behind a real proxy

hexajon referenced this issue from a commit

2026-10-16 00:20:23 +00:00

feat(adr): read a cross-forge decision-issue link on its own forge

hexajon referenced this issue

2026-10-16 00:20:23 +00:00

feat(adr): #632 read a cross-forge decision-issue link on its own forge #783

hexajon referenced this issue

2026-10-17 16:48:15 +00:00

bug(forge-test): the adr live forge test fails under the push-model runner, which ships no .git #795

hexajon commented

2026-10-17 16:48:55 +00:00

Author

Owner

The code for this landed on main, and the unit and fake-forge tests pass. The adr forge-tagged test package does not run green in the throwaway-forge VM yet: the live forge test cannot resolve a forge checkout, because the committed runner ships the tree with git archive and no .git. Tracked in #795. Keeping this open until the live forge run is green.

The code for this landed on main, and the unit and fake-forge tests pass. The adr forge-tagged test package does not run green in the throwaway-forge VM yet: the live forge test cannot resolve a forge checkout, because the committed runner ships the tree with `git archive` and no `.git`. Tracked in #795. Keeping this open until the live forge run is green.

hexajon added a new dependency

2026-10-18 03:00:06 +00:00

#795 bug(forge-test): the adr live forge test fails under the push-model runner, which ships no .git

hexajon commented

2026-10-18 05:23:09 +00:00

Author

Owner

The v0.20.0 breaking set is complete and green on main. The code landed across the v0.20.0 branches, the full local gate passes, and the forge suite is green on both forges at both pinned versions on current main (31693766). Closing as done.

The v0.20.0 breaking set is complete and green on main. The code landed across the v0.20.0 branches, the full local gate passes, and the forge suite is green on both forges at both pinned versions on current main (31693766). Closing as done.

hexajon removed a dependency

2026-10-18 05:24:37 +00:00

#674 epic: run forge tests against throwaway Forgejo and Gitea servers behind a real proxy

hexajon closed this issue

2026-10-18 05:25:18 +00:00

Rows
Columns

adr check: C11 drops the host from an issue URL and reads the link on the record's own forge #632

What happens

Expected

Acceptance criteria