chore: point MSD at git.golem15.com/golem15/msd-core

The fork lives on the golem15 Gitea forge, not GitHub. Package identity now
parses either host and derives in-place raw URLs for Gitea; the identity-drift
lint accepts the new host; README drops GitHub-only badges and the npm
quickstart in favour of the checkout installer.

docs/research/2026-08-30-coverage-merge-oom.md

@@ -24,7 +24,7 @@ Exit code 134 = 128 + SIGABRT (signal 6). V8 emits `FATAL ERROR: Ineffective mar
 
 ## 3. Runner headroom
 
-`finalize` runs on plain `runs-on: ubuntu-latest` (`.github/workflows/release.yml:547`, no `runs-on:` overrides), which is `golem15com/msd-core` — a public repo — so it gets GitHub's **public-repo standard Linux runner: 4 vCPU, 16 GB RAM, 14 GB SSD** ([GitHub Docs: Supported runners and hardware resources](https://docs.github.com/en/actions/reference/github-hosted-runners-reference)). Against 16 GB physical RAM, the current `--max-old-space-size=6144` (6 GB) leaves meaningful headroom before an OS-level OOM-kill — raising the flag further (e.g. to 10-12 GB) is a viable stopgap purely on paper, but it is treating the symptom: the underlying `_loadReports()` call still holds every raw V8 file for the whole 1785-test run in memory simultaneously before merging, so the ceiling will eventually be hit again as the suite grows, same as it was hit after the *first* raise from whatever the previous default was to 6144. GitHub-hosted "larger runners" (paid, up to 64 GB) are available as a deferred escape hatch if a real fix is not shipped, but they cost money and still only delay the same unbounded-memory-shape problem.
+`finalize` runs on plain `runs-on: ubuntu-latest` (`.github/workflows/release.yml:547`, no `runs-on:` overrides), which is `golem15/msd-core` — a public repo — so it gets GitHub's **public-repo standard Linux runner: 4 vCPU, 16 GB RAM, 14 GB SSD** ([GitHub Docs: Supported runners and hardware resources](https://docs.github.com/en/actions/reference/github-hosted-runners-reference)). Against 16 GB physical RAM, the current `--max-old-space-size=6144` (6 GB) leaves meaningful headroom before an OS-level OOM-kill — raising the flag further (e.g. to 10-12 GB) is a viable stopgap purely on paper, but it is treating the symptom: the underlying `_loadReports()` call still holds every raw V8 file for the whole 1785-test run in memory simultaneously before merging, so the ceiling will eventually be hit again as the suite grows, same as it was hit after the *first* raise from whatever the previous default was to 6144. GitHub-hosted "larger runners" (paid, up to 64 GB) are available as a deferred escape hatch if a real fix is not shipped, but they cost money and still only delay the same unbounded-memory-shape problem.
 
 ## 4. Options considered
 

docs/research/3875-ack-sweep-automation-failure.md

@@ -87,11 +87,11 @@ Contrary to the initial framing, this check **passed** (`gh pr checks 3927`: `Pu
 - The sweep's PR body (`ack-fragment-sweep.yml:243-261`) is freeform prose — no `## Fix PR` / `## Enhancement PR` / `## Feature PR` heading, none of the required headings in `TEMPLATES` (`pr-template-policy.cjs:55-97`).
 - The changed-files carve-out does not apply: `tests/emitted-drift-acks/*.json` is not in `TOOLING_PATH_ALLOWLIST` (`pr-template-policy.cjs:24-43`), so `allPathsAreTooling` returns `false`.
 - `matchingTemplate()` finds no heading match → `template: null` → falls to `reason = 'PR body does not match the fix, enhancement, or feature template.'`, `valid: false` (`pr-template-policy.cjs:217-223`).
-- The consequence is gated on **author trust**, not template compliance (`pr-template-policy.cjs:226-229`): `action = trusted ? 'warn' : 'close'`. `TRUSTED_AUTHOR_ASSOCIATIONS` includes `MEMBER` (line 6-11). The PR's actual author association is `MEMBER` (`gh api repos/golem15com/msd-core/pulls/3927 --jq '.author_association'` → `MEMBER`), because the workflow authenticates `gh pr create` with `MSD_BOT_PR_TOKEN` — a personal-access token belonging to a real maintainer account (`trek-e`), not a GitHub App/bot identity. So `action: warn`: the `msd-pr-template-policy` bot comment fires (`core.warning`, `pr-template-format.yml`'s "Warn trusted contributor" step), but the workflow only `core.setFailed`s on `action == 'close'` — never reached. The template body is objectively wrong; the check is objectively green.
+- The consequence is gated on **author trust**, not template compliance (`pr-template-policy.cjs:226-229`): `action = trusted ? 'warn' : 'close'`. `TRUSTED_AUTHOR_ASSOCIATIONS` includes `MEMBER` (line 6-11). The PR's actual author association is `MEMBER` (`gh api repos/golem15/msd-core/pulls/3927 --jq '.author_association'` → `MEMBER`), because the workflow authenticates `gh pr create` with `MSD_BOT_PR_TOKEN` — a personal-access token belonging to a real maintainer account (`trek-e`), not a GitHub App/bot identity. So `action: warn`: the `msd-pr-template-policy` bot comment fires (`core.warning`, `pr-template-format.yml`'s "Warn trusted contributor" step), but the workflow only `core.setFailed`s on `action == 'close'` — never reached. The template body is objectively wrong; the check is objectively green.
 
 ### B8. `Required tests` / `test (ubuntu-latest, 24)` — the fast-signal lane ran the WHOLE suite and hit its own 15-minute cap
 
-`gh run view 33059472019 --repo golem15com/msd-core --log-failed` and the per-job API (`jobs/98474440239`, `jobs/98478252101`) show:
+`gh run view 33059472019 --repo golem15/msd-core --log-failed` and the per-job API (`jobs/98474440239`, `jobs/98478252101`) show:
 
 - `test (ubuntu-latest, 24)` — the **unsharded** matrix entry (`.github/workflows/test.yml:198-200`: `{os: ubuntu-latest, node-version: 24, scope: targeted}`, no `shard` key, hence the bare job name per the `name:` template at `test.yml:130`) — started `09:38:38Z`, its "Run scoped tests" step ran from `09:39:10Z` to `09:53:51Z` (14m41s), and the whole job was marked `cancelled` at `09:53:56Z`, total **15m18s** — exactly the job's `timeout-minutes: 15` cap (`test.yml:155`).
 - The raw log for that job shows `run-tests: suite="all" files=827` at `09:39:11Z`, and the job reached only `chunk 13/14` before being killed (`chunk 13/14 — 61 files` at `09:52:37Z`) — i.e. it was running virtually the entire test corpus (827 files) in one unsharded process, not a narrow "targeted/fast-signal" subset. The three actually-sharded ubuntu `scope: full` jobs (which exist precisely to spread this same corpus across 3 runners, per the `#2952`/`#3057` comments at `test.yml:141-164`) all finished successfully in 6-9 minutes each.
@@ -101,7 +101,7 @@ Contrary to the initial framing, this check **passed** (`gh pr checks 3927`: `Pu
 
 ### B9. How #3927 was actually merged despite red required checks
 
-`gh api repos/golem15com/msd-core/pulls/3927 --jq '.merged_by.login, .merge_commit_sha, .author_association'` → `trek-e`, `ad6abc896...`, `MEMBER`. The PR was opened `09:38:15Z` and merged `12:16:49Z` (2h38m later) by the same account, `trek-e` (a human maintainer, `is_bot: false` per `gh pr list ... --json mergedBy`). The timeline (`gh api .../issues/3927/timeline`) shows only `review_requested` → two bot `commented` events → `merged`/`closed`/`head_ref_deleted`, all attributed to `trek-e` or `github-actions[bot]`; no re-run or re-triggered check event appears between open and merge. `gh pr checks 3927` (queried post-merge) still reports `validate-title fail` and `Required tests fail` as the latest, final state of those checks — they were never turned green. The merge therefore landed with required checks still red: a maintainer override (admin merge / branch-protection bypass), not an automatic pass triggered by the automation.
+`gh api repos/golem15/msd-core/pulls/3927 --jq '.merged_by.login, .merge_commit_sha, .author_association'` → `trek-e`, `ad6abc896...`, `MEMBER`. The PR was opened `09:38:15Z` and merged `12:16:49Z` (2h38m later) by the same account, `trek-e` (a human maintainer, `is_bot: false` per `gh pr list ... --json mergedBy`). The timeline (`gh api .../issues/3927/timeline`) shows only `review_requested` → two bot `commented` events → `merged`/`closed`/`head_ref_deleted`, all attributed to `trek-e` or `github-actions[bot]`; no re-run or re-triggered check event appears between open and merge. `gh pr checks 3927` (queried post-merge) still reports `validate-title fail` and `Required tests fail` as the latest, final state of those checks — they were never turned green. The merge therefore landed with required checks still red: a maintainer override (admin merge / branch-protection bypass), not an automatic pass triggered by the automation.
 
 ### B10. No auto-merge path exists for the sweep PR
 
@@ -109,11 +109,11 @@ Contrary to the initial framing, this check **passed** (`gh pr checks 3927`: `Pu
 
 ### B11. `MSD_BOT_PR_TOKEN` fallback warning did NOT fire — ruled out as a cause
 
-`gh run view 33059445125 --repo golem15com/msd-core --log` (the sweep workflow's own run) shows the "Open the sweep PR" step's env block: `HAS_BOT_TOKEN: 1`. The step's guard is `if [ -z "${HAS_BOT_TOKEN:-}" ]; then echo '::warning::MSD_BOT_PR_TOKEN is unset...'; fi` (`ack-fragment-sweep.yml:191-193`) — with `HAS_BOT_TOKEN=1` this branch is skipped, and indeed no such warning line appears anywhere in the run log. `MSD_BOT_PR_TOKEN` **was** configured and used. This is corroborated independently by B7/B9: the PR's `author_association` is `MEMBER` (not the unauthenticated-fallback shape) and the title/template *required* checks did run and report real verdicts (`validate-title`, `Pull request template format` both executed) — under the `GITHUB_TOKEN` fallback the workflow's own comment (`ack-fragment-sweep.yml:189`) states "no required checks will run on it," which is not what happened. **The fallback-token hypothesis is not the cause of this hang.** (Git commit authorship on the branch itself still reads `github-actions[bot]` per `git config user.name` at `ack-fragment-sweep.yml:204-205` — a separate, cosmetic identity from the `gh` API actor, which is `trek-e` via the PAT.)
+`gh run view 33059445125 --repo golem15/msd-core --log` (the sweep workflow's own run) shows the "Open the sweep PR" step's env block: `HAS_BOT_TOKEN: 1`. The step's guard is `if [ -z "${HAS_BOT_TOKEN:-}" ]; then echo '::warning::MSD_BOT_PR_TOKEN is unset...'; fi` (`ack-fragment-sweep.yml:191-193`) — with `HAS_BOT_TOKEN=1` this branch is skipped, and indeed no such warning line appears anywhere in the run log. `MSD_BOT_PR_TOKEN` **was** configured and used. This is corroborated independently by B7/B9: the PR's `author_association` is `MEMBER` (not the unauthenticated-fallback shape) and the title/template *required* checks did run and report real verdicts (`validate-title`, `Pull request template format` both executed) — under the `GITHUB_TOKEN` fallback the workflow's own comment (`ack-fragment-sweep.yml:189`) states "no required checks will run on it," which is not what happened. **The fallback-token hypothesis is not the cause of this hang.** (Git commit authorship on the branch itself still reads `github-actions[bot]` per `git config user.name` at `ack-fragment-sweep.yml:204-205` — a separate, cosmetic identity from the `gh` API actor, which is `trek-e` via the PAT.)
 
 ## C. Track record — is #3927 representative or a one-off?
 
-`gh pr list --repo golem15com/msd-core --search "head:chore/ack-sweep" --state all --limit 30 --json number,title,state,createdAt,mergedAt,mergedBy` returns **exactly one PR**: #3927 itself (opened `09:38:15Z`, merged `12:16:49Z`, `mergedBy: trek-e`). There is no prior sweep PR to compare against — this is the automation's first (and so far only) production run that produced a non-empty plan and opened a PR. It cannot yet be called "systematically failing" by volume, but the failure mechanism identified in B8 is a property of the scope-classification table and the sweep's title-generation code, not of this specific run's data — so it will reproduce on the *next* sweep PR with high confidence, absent a fix to either `ack-fragment-sweep.yml`'s title format or `scripts/ci-test-scope.cjs`'s `RULES` table (or both).
+`gh pr list --repo golem15/msd-core --search "head:chore/ack-sweep" --state all --limit 30 --json number,title,state,createdAt,mergedAt,mergedBy` returns **exactly one PR**: #3927 itself (opened `09:38:15Z`, merged `12:16:49Z`, `mergedBy: trek-e`). There is no prior sweep PR to compare against — this is the automation's first (and so far only) production run that produced a non-empty plan and opened a PR. It cannot yet be called "systematically failing" by volume, but the failure mechanism identified in B8 is a property of the scope-classification table and the sweep's title-generation code, not of this specific run's data — so it will reproduce on the *next* sweep PR with high confidence, absent a fix to either `ack-fragment-sweep.yml`'s title format or `scripts/ci-test-scope.cjs`'s `RULES` table (or both).
 
 ## Open questions