documentation is inconsistent about linking to forgejo vs github

coilysiren commented

2026-07-01 21:55:25 +00:00

Owner

TBH I am inconsistent about that myself...

The rule is github for everyone except me, forgejo for me. A lot of that can be encoded via relative URLs, but much of it can't

TBH I am inconsistent about that myself... The rule is github for everyone except me, forgejo for me. A lot of that can be encoded via relative URLs, but much of it can't

coilyco-ops added this to the ward launch milestone

2026-07-01 23:29:48 +00:00

coilyco-ops added the

labels

2026-07-01 23:30:36 +00:00

coilyco-ops referenced this issue

2026-07-01 23:58:18 +00:00

README's first sentence conflates dev-verb wrapping (forge-agnostic) with agent-carries-a-Forgejo-issue (Forgejo-only), losing GitHub-only adopters of the half that would actually work for them #461

coilyco-ops commented

2026-07-01 23:58:20 +00:00

Owner

DECISION - rule updated during triage: ALL external/public-facing copy references GitHub only; Forgejo appears in contributor-facing surfaces (CONTRIBUTING, AGENTS.md, source). Encode the rule in the #446 linter so it stays true. Recorded by Claude Code (Fable) during the 2026-07-01 ward launch triage session with Kai.

coilyco-ops referenced this issue

2026-07-01 23:58:21 +00:00

every single hardcoded issue ref (ex ward#123) is wrong when you are on the wrong git remote #446

coilyco-ops referenced this issue

2026-07-02 00:01:42 +00:00

meta: jul 1st evening sprint - launch burndown session 1 #492

coilyco-ops referenced this issue

2026-07-02 00:20:38 +00:00

Use decode into rg pattern to keep clear of custom code #193

coilysiren referenced this issue

2026-07-02 02:52:38 +00:00

README's first sentence conflates dev-verb wrapping (forge-agnostic) with agent-carries-a-Forgejo-issue (Forgejo-only), losing GitHub-only adopters of the half that would actually work for them #461

coilyco-ops commented

2026-07-02 03:15:38 +00:00

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-443 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T03:15:36Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-443` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T03:15:36Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-07-02 04:30:51 +00:00

Owner

🔒 Reserved by ward agent --driver codex — container engineer-codex-ward-443 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T04:30:50Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Codex, via ward agent

🔒 Reserved by `ward agent --driver codex` — container `engineer-codex-ward-443` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T04:30:50Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Codex, via `ward agent`

coilysiren referenced this issue from a commit

2026-07-02 04:32:33 +00:00

Clarify Forgejo vs GitHub documentation

coilysiren closed this issue

2026-07-02 04:32:33 +00:00

coilysiren commented

2026-07-02 04:32:45 +00:00

Author

Owner

WARD-OUTCOME: done - clarified the GitHub-vs-Forgejo contributor wording in README and the PR template

The doc drift was small but real: the repo already had the right policy in the CONTRIBUTING flow, but the surrounding copy was easy to read two different ways. The fix was straightforward, though I had to be careful to phrase the maintainer exception without muddying the public front door rule. Confidence is high; the only rough edge is that this class of wording issue tends to crop up in multiple docs at once, so I would watch for similar phrasing elsewhere.

WARD-OUTCOME: done - clarified the GitHub-vs-Forgejo contributor wording in README and the PR template The doc drift was small but real: the repo already had the right policy in the CONTRIBUTING flow, but the surrounding copy was easy to read two different ways. The fix was straightforward, though I had to be careful to phrase the maintainer exception without muddying the public front door rule. Confidence is high; the only rough edge is that this class of wording issue tends to crop up in multiple docs at once, so I would watch for similar phrasing elsewhere.

coilyco-ops commented

2026-07-02 07:53:46 +00:00

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-443 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T07:53:43Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-443` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T07:53:43Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-07-02 07:53:49 +00:00

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-443 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T07:53:43Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-443` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T07:53:43Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-07-02 07:53:53 +00:00

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-443 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T07:53:43Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-443` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T07:53:43Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-02 08:00:29 +00:00

docs: codify the Forgejo-vs-GitHub linking convention (ward#443)

coilysiren commented

2026-07-02 08:01:05 +00:00

Author

Owner

WARD-OUTCOME: done - wrote the Forgejo-vs-GitHub linking rule down as docs/forge-linking.md + an AGENTS.md rule, and fixed a dead [SECURITY.md] link in the README.

Honest read: the surprise was how little of the content was actually wrong. The public surfaces (CONTRIBUTING, the templates, github-mirror.md, the README Support section) already route external readers to GitHub and keep Forgejo for canonical facts - the two-forge split was implemented, just never stated anywhere as a rule you could check a link against. So the real gap was a missing convention, not scattered mistakes. I codified it as three cases (same-repo -> relative, external navigation -> GitHub, canonical/infra -> Forgejo) so the relative-link case dissolves most of the ambiguity on its own.

What fought back: the doc-size caps. The README had ~7 chars of headroom and my SECURITY.md fix pushed it over, and github-mirror.md sat exactly at the 80-line cap with zero room, so my first instinct (drop the rule into github-mirror.md) didn't fit. Splitting it into its own small doc was the right shape anyway. I also caught that github-mirror.md wasn't in the docs index at all and added it.

Confidence is high - it's docs only, all pre-commit hooks pass, and the merge was clean. One genuine bug fixed along the way (the reference-style [SECURITY.md] link rendered as literal text). Rough edge / possible follow-up: there's no lint that enforces the convention (e.g. flagging an absolute forge URL to a same-repo file that could be relative), so it still relies on authors reading the rule. Worth a hook someday if the drift comes back.

WARD-OUTCOME: done - wrote the Forgejo-vs-GitHub linking rule down as docs/forge-linking.md + an AGENTS.md rule, and fixed a dead [SECURITY.md] link in the README. Honest read: the surprise was how little of the *content* was actually wrong. The public surfaces (CONTRIBUTING, the templates, github-mirror.md, the README Support section) already route external readers to GitHub and keep Forgejo for canonical facts - the two-forge split was implemented, just never stated anywhere as a rule you could check a link against. So the real gap was a missing convention, not scattered mistakes. I codified it as three cases (same-repo -> relative, external navigation -> GitHub, canonical/infra -> Forgejo) so the relative-link case dissolves most of the ambiguity on its own. What fought back: the doc-size caps. The README had ~7 chars of headroom and my SECURITY.md fix pushed it over, and github-mirror.md sat exactly at the 80-line cap with zero room, so my first instinct (drop the rule into github-mirror.md) didn't fit. Splitting it into its own small doc was the right shape anyway. I also caught that github-mirror.md wasn't in the docs index at all and added it. Confidence is high - it's docs only, all pre-commit hooks pass, and the merge was clean. One genuine bug fixed along the way (the reference-style [SECURITY.md] link rendered as literal text). Rough edge / possible follow-up: there's no lint that *enforces* the convention (e.g. flagging an absolute forge URL to a same-repo file that could be relative), so it still relies on authors reading the rule. Worth a hook someday if the drift comes back.

coilysiren referenced this issue

2026-07-02 08:17:23 +00:00

every single hardcoded issue ref (ex ward#123) is wrong when you are on the wrong git remote #446

Rows
Columns

documentation is inconsistent about linking to forgejo vs github #443