adr: the released madtea only knows docs/adr and tells a MADR repo to create a legacy tree #488

New issue

Open

opened 2026-09-14 21:01:51 +00:00 by hexajon · 0 comments

hexajon commented

2026-09-14 21:01:51 +00:00

Owner

What happens

In a repo whose records live in docs/decisions/ (MADR 4.0.0), madt_adr action=new from a build that predates 6bb57261 fails with:

no docs/adr directory found under <repo> - create it (with a README.md index) before adding records

I hit this with a dev build from 9bce364d (2026-09-09). v0.18.5, the latest release, is older still, so every user on a release gets the same result. The advice is wrong for a MADR repo: it points the user at the legacy docs/adr/ layout.

State on main

main is correct. 6bb57261 added MADR 4.0.0 support:

internal/service/adr/adr.go New and Check call detectLayout. A docs/decisions/ tree runs MADR mode, a docs/adr/ tree runs legacy mode, and a repo with neither gets "run adr init to create docs/decisions/, or add a legacy docs/adr/ tree".
The legacy-only messages (adr.go:205, adr.go:330) are reached only in legacy mode.
go run ./cmd/madtea adr new <slug> in this repo creates docs/decisions/0035-... correctly.

So nothing is wrong in the source. The MADR support has not shipped yet.

Ask

Ship the MADR support in the next release, and check it on the released binary.

Acceptance

The next release contains 6bb57261.
With the released binary, madt_adr action=new and madtea adr new in a docs/decisions/ repo create the record and its index row. madt_adr action=check checks the tree.
In a repo with neither tree, the released binary points at adr init, not at creating docs/adr/.

## What happens In a repo whose records live in `docs/decisions/` (MADR 4.0.0), `madt_adr action=new` from a build that predates `6bb57261` fails with: ``` no docs/adr directory found under <repo> - create it (with a README.md index) before adding records ``` I hit this with a dev build from `9bce364d` (2026-09-09). v0.18.5, the latest release, is older still, so every user on a release gets the same result. The advice is wrong for a MADR repo: it points the user at the legacy `docs/adr/` layout. ## State on main `main` is correct. `6bb57261` added MADR 4.0.0 support: - `internal/service/adr/adr.go` `New` and `Check` call `detectLayout`. A `docs/decisions/` tree runs MADR mode, a `docs/adr/` tree runs legacy mode, and a repo with neither gets "run `adr init` to create docs/decisions/, or add a legacy docs/adr/ tree". - The legacy-only messages (`adr.go:205`, `adr.go:330`) are reached only in legacy mode. - `go run ./cmd/madtea adr new <slug>` in this repo creates `docs/decisions/0035-...` correctly. So nothing is wrong in the source. The MADR support has not shipped yet. ## Ask Ship the MADR support in the next release, and check it on the released binary. ## Acceptance - The next release contains `6bb57261`. - With the released binary, `madt_adr action=new` and `madtea adr new` in a `docs/decisions/` repo create the record and its index row. `madt_adr action=check` checks the tree. - In a repo with neither tree, the released binary points at `adr init`, not at creating `docs/adr/`.

hexajon added the

bug

label

2026-09-14 21:01:51 +00:00

hexajon referenced this issue

2026-09-15 21:07:16 +00:00

decision: should adr check's linked-issue rule run for every MADR repo, or only where a repo turns it on? #494

hexajon referenced this issue

2026-09-15 21:07:32 +00:00

Epic: adr tooling guides the author, not only fails #496

hexajon referenced this issue

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