docs(ISSUE-WP-0006): Forgejo-only language and projection boundary

Prefer Forgejo as the self-hosted forge product. Keep Gitea only as the
Gitea-compatible API identifier (module backends/gitea, type string
gitea). FORGEJO_TOKEN is preferred; GITEA_* remains a deprecated alias.

INTENT/SCOPE quote ACT-ADR-005: issue-core is not the fleet ops claim
queue. Connector docs describe repo work record → hub index → optional
Forgejo projection, not activity-core → issue-core → harness.

Assistant: grok
Assistant-Session: 01a09dc6-3f0d-7c93-8b11-8e83c0623d49

docs/boundary-sync-and-status-mapping.md

@@ -21,7 +21,7 @@
 | Side | Key |
 | --- | --- |
 | Work record | **UUIDv7** (bookkeeping); canonical id optional denorm for UX |
-| External | `(backend, external_id)` where backend is `sqlite` \| `gitea` \| … |
+| External | `(backend, external_id)` where backend is `sqlite` \| `gitea` (Forgejo) \| … |
 
 ## Outward status table (task kind + pass-through)
 

docs/intent-work-record-alignment-review.md

@@ -87,7 +87,7 @@ without naming UUIDv7 or the human-facing id.
 **Why it matters:** Mapping implementation and CLI (`issue project
 ISSUE-WP-…`) will almost always start from the **canonical name**; storage
 key should be UUID. INTENT’s UUID-only phrasing can steer readers to hide
-canonical ids or treat Gitea numbers as peer identity to human task names.
+canonical ids or treat Forgejo numbers as peer identity to human task names.
 
 **Recommendation:** In INTENT “Why / Mapping”, say:
 
@@ -215,7 +215,7 @@ Framework makes `lane` mandatory on every work record; tags and budgets are
 normative.
 
 INTENT is silent — **acceptable** if projections never invent parallel
-lane/budget models on issues. Soft risk if Gitea labels start carrying a
+lane/budget models on issues. Soft risk if Forgejo labels start carrying a
 second autonomy model (`lane:green` as issue labels without mapping rules).
 
 **Recommendation:** Mapping/projection: lane, tags, budget stay on the work
@@ -231,7 +231,7 @@ INTENT’s “What it is” lists responsibilities that mix **shipped** and
 
 | Responsibility in INTENT | Shipped? |
 | --- | --- |
-| Projection / CRUD on backends | **Yes** (SQLite, Gitea) |
+| Projection / CRUD on backends | **Yes** (SQLite, Forgejo) |
 | Mapping UUID ↔ external id | **No** — design only |
 | Two-way boundary sync | **No** — CLI backend sync ≠ work-record boundary sync |
 | CLI + REST | **Yes** |
@@ -295,7 +295,7 @@ defaults, rewriting AGENT_INTEGRATION examples — those are separate work.
 | Connector role | Yes | Yes | Yes |
 | Not work origin | Yes | §3.1 | Yes |
 | Mapping | Target | Design + not shipped | Yes if INTENT softens “What it is” |
-| Backends | SQLite + Gitea (+ planned) | Same | Yes |
+| Backends | SQLite + Forgejo (+ planned) | Same | Yes |
 | REST TaskSpec | Optional intentional | Full contract | Yes |
 | State-hub runtime events from package | Downstream mention | Explicitly not shipped | Mild aspirational gap in older SCOPE; current SCOPE honest |
 

docs/package-release.md

@@ -15,7 +15,7 @@ make package-check
 Publish to the Coulomb organization registry:
 
 ```bash
-TWINE_USERNAME=<gitea-user> \
+TWINE_USERNAME=<forgejo-user> \
 TWINE_PASSWORD=<package-token> \
 make publish-forgejo
 ```

docs/uuid-external-id-mapping.md

@@ -11,13 +11,13 @@ kinds in `the-custodian/canon/standards/work-record-types_v0.1.md`
 
 ## Problem
 
-When collaboration requires a third-party tracker (Forgejo/Gitea, GitHub,
+When collaboration requires a third-party tracker (Forgejo, GitHub,
 Jira, …), the fleet still needs a stable link between:
 
 | Side | Identity today | Owner |
 | --- | --- | --- |
 | Internal work record | UUIDv7 written back as `state_hub_*_id` (workplan/task/intake/…) | repo file + state-hub |
-| External issue | Backend issue id / number (+ URL) | Gitea, GitHub, … via issue-core |
+| External issue | Backend issue id / number (+ URL) | Forgejo, GitHub, … via issue-core |
 
 Without an explicit mapping:
 
@@ -95,7 +95,7 @@ mapping:
   work_record_uuid: <uuidv7>         # primary internal key
   work_record_id: "ISSUE-WP-0004-T01"  # canonical name, optional denorm
   work_record_kind: task             # task | intake | workplan | …
-  backend: gitea                     # gitea | github | gitlab | jira | sqlite
+  backend: gitea                     # forgejo product; type string `gitea` | github | gitlab | jira | sqlite
   external_id: "176"                 # backend-native issue id/number
   external_url: "https://…/issues/176"
   target_repo: "coulomb/example"     # optional routing hint
@@ -123,7 +123,7 @@ issue-core only:
 ```yaml
 # on a task / intake YAML block (illustrative — exact key names TBD with canon)
 external_tracker:
-  backend: gitea
+  backend: forgejo                   # product; stored type may be `gitea`
   issue_id: "176"
   issue_url: "https://…"
   mapped_by: issue-core
@@ -132,7 +132,7 @@ external_tracker:
 Alternatively a single string field if canon prefers flat keys:
 
 ```text
-issue_core_external_ref: "gitea:coulomb/example#176"
+issue_core_external_ref: "forgejo:coulomb/example#176"
 ```
 
 Canon PR owns the field name; issue-core owns the mapping authority.
@@ -142,7 +142,7 @@ Canon PR owns the field name; issue-core owns the mapping authority.
 Recommended v1:
 
 1. **Local SQLite** table `work_record_issue_map` (even when primary CRUD
-   backend is Gitea) — mapping is fleet bookkeeping, not a Gitea concept.
+   backend is Forgejo) — mapping is fleet bookkeeping, not a Forgejo concept.
 2. **Issue.sync_metadata.mapping** (or top-level) echo for convenience when
    the issue is loaded:
    ```json
@@ -154,7 +154,7 @@ Recommended v1:
      }
    }
    ```
-3. Optional Gitea label / body footer for human visibility in the tracker UI
+3. Optional Forgejo label / body footer for human visibility in the tracker UI
    (non-authoritative).
 
 ### API / CLI (sketch only)
@@ -255,7 +255,7 @@ increment. Until enabled, connector load is zero beyond idle process cost.
   documenting multi-tracker projection is future work.
 - **SQLite-only offline:** mapping table lives with local DB; sync of
   issues and mappings to remote is coordinated (mapping rows are not
-  pushed as Gitea native objects).
+  pushed as Forgejo native objects).
 
 ## Implementation sketch (later workplan)