[magnum8237]

⚠️ base-red inherited: #17219

What

Documentation only. Closes the gap that let a production repair sit outside git for two and a
half months in the shared main checkout.

• AGENTS.md → Git Workflow → new subsection "Shared-checkout changes must not go orphan",
  placed immediately after "Worktree isolation". Rule docs: add npm badge, CLI options, and release workflow to README #19 keeps development out of the shared
  checkout; this covers what is already sitting in it.
• AGENTS.md → Hard Rule feat: domain layer, error codes, request ID, fetch timeout (Batch A) #24, short form pointing at that subsection.
• Rule-count bump 23 → 24 Hard Rules in CLAUDE.md, GEMINI.md and
  docs/i18n/phi/CLAUDE.md (the only one of the 66 locale mirrors that states the count).

Numbering: Hard Rule #23 (_tasks/ é INTOCÁVEL) already exists on this base, so the new
rule is #24. Nothing was renumbered — the preamble's "rule numbers are stable" holds.

The rule has four parts:

1. "Local repair, not feature development" is not a parking space. It stays a legitimate
   reason to touch the shared tree to get a service running again; it stops being a reason for
   the work to live outside git. Every change there ends the session either committed on a
   branch of its own (the PR can come later) or recorded as a known divergence — an open issue
   naming the files, why it was not committed, and a review date. There is no third state.
2. A production build regenerated from an uncommitted tree is declared in that same issue.
   The served build then depends on code that exists in no commit, so discarding the working
   tree and rebuilding takes production down with no warning and no trace of what was lost.
3. Never measure pending work against the local HEAD. Resolve the active release branch
   first (the highest release/v* on origin) and diff against that. A stale checkout reports
   already-merged code as pending work.
4. A verification command read from a stale checkout may already have been corrected
   upstream, and such a command usually fails silently — returning nothing instead of
   erroring — so a red base reads as green. Re-check it against the active release branch before
   trusting what it reports.

Why — two incidents, same root cause

2026-08-15 — work lost to the classification. A build-breaking repair (the #9199 merge
residue that threw a ReferenceError and took down the model catalog and the dashboard screens)
was applied straight to the shared main checkout and classified "local repair solicited by the
operator, not feature development". That classification is what kept it from ever becoming a
branch or a PR. The production build serving port 20128 was then regenerated from that working
tree, and the watchdog only rebuilds when BUILD_ID is absent — so the running service came to
depend on code held in no commit at all.

2026-10-29 — triage against the real baseline. The tree still read as ~90 pending changes:

Claim	Verified
The repair had already landed upstream	37d70785c7 — "fix(build): repair broken production build, red lint gate and SWR crash (#10198)", merged 2026-08-12 15:58, i.e. after the local HEAD 838e4d688
How much of the snapshot was already upstream	15 of 88 files in that commit, 13 byte-identical
How much was still needed	13 of 88 files; 75 discardable, 3 of which would have introduced defects if carried over
How stale the checkout was	local HEAD 5,266 commits behind release/v3.8.53

2026-10-29 — the same stale file then corrupted the verification itself, which is why part 4
exists. The main checkout's AGENTS.md still carries a base-green query naming the pre-rename
repository (diegosouzapw/OmniRoute, which now redirects to cheaper-inference/OmniRoute).
gh issue list --search does not follow that redirect — it resolves to nothing and exits 0.
So the open base-red issue #17219 for release/v3.8.53 read as "no issue" across several
sessions working this campaign, a red base looked green, and the CI failures inherited from the
base looked like each contributor's own defect. Reproduced both ways while preparing this PR:

old name       → 0 rows
canonical name → 1 row  (#17219 🔴 Release branch not green: release/v3.8.53)

An earlier revision of this very PR body claimed "no open base-red issue exists" — produced by
that same stale command, from the same stale file. It is corrected above. That is the failure
mode part 4 describes: not work lost, but a check that lies quietly and moves the blame onto the
contributor.

Every figure in the table was re-verified against origin/release/v3.8.53 in the session that
opened this PR (git log, gh pr view 10198, git merge-base --is-ancestor,
git rev-list --count) rather than taken from the triage report. The full report lives in the
separate, gitignored _tasks repo at
_tasks/research/2026-10-29-triagem-reparo-local-2026-08-15.md.

Gates

npm run check:docs-all, run by hand — 5 of 7 green; the 2 failures are inherited from the
base tip (#17219) and are not touched by this diff:

Gate	Result
check:docs-sync	✅ PASS (66 locale mirrors validated)
check:docs-frontmatter	❌ inherited — docs/providers/GITHUB-COPILOT.md, docs/providers/grok-cli-media.md lack frontmatter
check:docs-counts	❌ inherited — 95 strict drifts (66 × docs/i18n/*/README.md "213 migrations" vs 214, plus AGENTS.md's own stale "377 LLM providers" / "213 migrations" on lines 32/40)
check:env-doc-sync	✅ PASS
check:deprecated-versions	✅ PASS (soft warnings only)
check:doc-links	✅ PASS — 1263 internal links
check:fabricated-docs	✅ PASS — no fabricated API/env/CLI/file references

Proof the two failures are not mine: both gates were run against a pristine export of
origin/release/v3.8.53 (git archive, no local changes) and produced the identical
frontmatter failure and drift count; the stale counts flagged in AGENTS.md are its existing
lines 32 and 40, and this diff adds zero lines containing those numbers, nor any file under
docs/providers/ or any README.md. Per Git Workflow → "Base-green check" the inherited
failures were deliberately not fixed here — a base-red fix is its own freeze-gated
fix/release-vX.Y.Z-basereds PR. No release-freeze is active (checked against the canonical
repository name).

Notes for the reviewer

• local-divergence label: the rule names this as the marker label for a recorded
  divergence, in the same spirit as the existing release-freeze / base-red / needs-vps
  markers. It does not exist in the repo yet — the text says "created on first use", and no
  label was created by this PR.
• protected-surface: this PR touches agent-instruction surfaces (AGENTS.md, CLAUDE.md,
  GEMINI.md), so it needs that label and the per-PR operator OK before merging. The account
  that opened it has read-only access upstream and cannot apply labels — please add it.
• Scope: policy only. The .husky/_ / cp -al worktree recipe in the adjacent "Worktree
  isolation" subsection is deliberately untouched — a separate PR owns that fix, so a reviewer
  can approve either without blocking the other.
• No code, no quality-baseline.json, no gate changes. Built in an isolated worktree under
  .claude/worktrees/; the shared main checkout was not touched.
• CI state, and auto-fix deliberately off. As a cross-fork PR every workflow is parked at
  action_required: GitHub will not run CI until a maintainer approves the workflow runs, so the
  absence of checks here is neither a green nor a red. When they do run, this PR inherits the
  base tip's failures — 🔴 Release branch not green: release/v3.8.53 #17219 records 8 hard failures on release/v3.8.53, and its
  ci.yml:docs-sync-strict → npm run check:docs-all entry is README stale-version drift
  (OmniRoute 3.8.52 … vs package.json 3.8.53), which is the same check:docs-counts README
  drift measured locally above. The session's CI auto-fix automation was therefore switched
  off for this PR: reacting to those failures would mean repairing base-red inside a feature
  branch, which Git Workflow → "Base-green check" forbids. Please compare any red check here
  against 🔴 Release branch not green: release/v3.8.53 #17219 before attributing it to this diff — which is exactly what that issue's own
  header asks reviewers to do.