docs: delete the phantom auth-failure alert and its two signal listings

[os-zhuang]

Fixes#87

auth_failures_total is emitted by nothing, so ObjectOSAuthFailureSpike is an alert that stays green forever. It is deleted rather than reworded, and the two other places that recommended the same signal are corrected with it.

Premise re-verified

Independently re-measured on objectstack@origin/main at b057e53f4, with the reverse control a zero-hit needs:

git grep auth_failures_total origin/main → 0 files
git grep -l SEMCONV origin/main → 15 files ← control: grep and tree are fine

packages/observability/src/semconv.ts declares 13 names across HTTP, storage, cache, jobs and the package registry. No auth metric among them. The card is right.

The third option was measured, then rejected

#87 offered a cheap alternative to delete-or-wait: express the alert against http_requests_total{status=~"40[13]"}. Its own caveat was the part to test, so I read how the runtime actually answers before adopting it. It does not honestly cover what the alert claimed — three independent reasons, any one of which is disqualifying:

1. The sign-in endpoints do not feed that counter at all.http_requests_total has exactly one emitter, instrumentRouteHandler (packages/runtime/src/observability/instrument.ts:106). It is applied by a Proxy that dispatcher-plugin.ts:700-721 builds over a localserver binding from ctx.getService('http.server'), never registered back as the service. plugin-auth mounts its routes on the raw Hono app — getRawApp(), then rawApp.all(basePath + '/*') (auth-plugin.ts:1622,2240). A failed password on /api/v1/auth/sign-in/email increments nothing.
2. A rejected API key is indistinguishable from no credential.core/src/security/api-key.ts validates fail-closed by design — "anything ambiguous (missing, revoked, expired, malformed) resolves to no principal" — so a presented-and-rejected key and a request that carried nothing both arrive anonymous and both answer 401. This is exactly the case the card flagged as uncertain.
3. 401/403 are dominated by traffic that is not an auth failure. 403 is this runtime's authorization code — PERMISSION_DENIED, export-permission denials, share-link denials, NOT_OVERRIDABLE, docs permission sets, the ADR-0069 auth gate (password expiry / enforced MFA) — all raised against users who authenticated perfectly well. 401 is every ordinary anonymous request.

So deleting is the better answer, which is the outcome the dispatch named as a good one.

What the pages say now, and what that does and does not cover

No alert is kept, so there is no YAML coverage claim to make. The replacement is prose, and here is precisely what it asserts:

• It does cover telling an operator that no auth-failure series exists, so they stop looking for one, and that 401/403 counting is not a substitute — with the reason, so the next reader does not re-derive the idea and re-add the alert.
• It does not cover giving them an auth-failure signal. There is none. The pointer to the Console's Auth audit view is deliberately scoped to sign-in activity, not to failures: plugin-audit's AuthSessionAuditEvent is a closed login | logout union with a required real sys_user id, so the ledger records successful sessions only. The page does not claim otherwise, and operate/audit-logs.mdx already documents that view.

Changes

File	Change
content/docs/operate/observability.mdx	ObjectOSAuthFailureSpike deleted from the starter-alerts block; the Auth failures row deleted from the signal table above it; one paragraph added next to #86's cold-start paragraph, in that established shape
content/docs/resources/faq.mdx	"auth failure rate" removed from "What metrics should I monitor?"; one clause added pointing at the Auth audit view

Re-read both neighbourhoods before editing, as instructed: #86 landed in faq.mdx (this same answer, replacing "kernel cache miss rate" with readiness) and in the observability.mdx signal table (replacing the cache row with readiness) earlier today. Both edits sit on top of that, neither reverts it. English only; locale siblings go stale and are re-derived by the translation pass.

The other half of #87 is filed, not answered

Whether the runtime should emit an auth-failure metric is an objectstack roadmap question, not an objectos docs one. Filed unassigned with the evidence as objectstack-ai/objectstack#9623. If it lands, transcribing the name back here is a one-line follow-up.

Verification

All on fe78131, the head of this branch.

Check	Result
turbo run type-check --force	cache bypass, force executing 8c984641fb51da8e · 1 successful, 0 cached
turbo run build --force	cache bypass, force executing ade11cd4db19e8fa · 1 successful, 0 cached · 550+ doc paths prerendered
turbo run test	0 tasks — the docs app declares no test script (same as CI)
check-translation-ownership.mjs	passed · 0 translation artifacts touched, 2 other files
check-translations.mjs	✓ translations gate passed · both pages now listed stale, which is reported-not-blocking by design
check-translation-output.mjs --self-test	✓ 20 case(s), every rule demonstrated able to fail
check-translation-output.mjs --files	✓ gate passed · 110 pre-existing corpus findings, none in these two pages

Rendered HTML read for both pages against a real dev server, not inferred from the source:

• /docs/operate/observability — 200. The alert block now renders ObjectOS5xxSpike alone; the signal table renders 4 rows with no auth row; auth_failures_total and ObjectOSAuthFailureSpike each occur 0 times in the served HTML.
• /docs/resources/faq — 200. The answer renders as "5xx rate, p95 latency, readiness (/api/v1/ready), queue depth. There is no auth-failure metric to monitor — review sign-in activity in the Console's Auth audit view instead."; "auth failure rate" occurs 0 times.

Out of scope, reported not edited

• Sibling cards own glossary.mdx, quickstart.mdx and configure/runtime.mdx this round — untouched.
• faq.mdx still recommends monitoring "queue depth", a second signal the runtime does not emit #96 — the same FAQ sentence still recommends queue depth, which is also emitted by nothing (the only greps are placeholder names inside metrics-registry unit tests). Same defect class, different call, so filed rather than folded in.
• finding: AGENTS.md documents the docs dev server on port 3001; npm run dev is bare next dev and binds 3000 #97 — AGENTS.md documents the docs dev server on port 3001; npm run dev is bare next dev and binds 3000.

---

Generated by Claude Code