docs: drop "forge" jargon for concrete Gitea wording
test / integration (pull_request) Successful in 53s
test / integration (push) Successful in 57s
test / unit (pull_request) Successful in 33s
test / unit (push) Successful in 36s

We use Gitea, not an abstract forge. Reword the docs added in this
branch: "forge thread" -> "Gitea thread", and the research note's
generic "forge" -> "Gitea" / "hosting provider" as context demands,
keeping its portability argument coherent.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit was merged in pull request #97.
This commit is contained in:
2026-05-28 22:53:53 -04:00
parent 5c5f576df0
commit ae1531835d
4 changed files with 21 additions and 21 deletions
+2 -2
View File
@@ -1,7 +1,7 @@
# Product requirement docs
One PRD per feature: what to build, why, and how it's scoped. The PRD
is the durable spec — it should stand on its own without a forge issue
is the durable spec — it should stand on its own without a Gitea issue
thread (see [`../README.md`](../README.md) for when a PRD is the right
document vs. a research note or a decision record).
@@ -60,4 +60,4 @@ doesn't need (a small change rarely needs Scope or Implementation
chunks) and add others where they help (e.g. Testing strategy,
Alternatives considered, References). Keep the rationale self-contained
— inline the reasoning rather than linking out to an issue thread, so
the PRD survives a forge migration.
the PRD survives a move off Gitea.