connor
e6644d0616
Replaces the previous repo, which had split into two histories that never met (mainframe on a dead GitLab remote, the laptops on Gitea) with 146 dirty files across three machines and the NAS never enrolled at all. Branch-per-machine is gone. One main, with host differences expressed as small files under hosts/<hostname>/ rather than as branches, so there is nothing to merge. The reconciled zsh layer reduces 15-33 line forks to 1-7 effective lines per host; distro differences (oh-my-zsh prefix, syntax-highlighting path, fd vs fdfind) are probed in common/ instead. Fresh history: the old one carried six plaintext credentials, 45 MB of mail caches, browser caches and vendored binaries. 5,096 tracked files and 144 MB become 462 files and 2.6 MB. The .gitignore is now an allowlist, which is what keeps that true. Root cause of the rot: ~/.local/bin was a symlink to scripts/ with GOPATH inside it, so every go install wrote into version control (2.2 GB on the work laptop). PATH now points at the repo instead of the reverse. Also: Hyprland replaces sway and is sourced in two halves so $browser is defined before use; singleton automations carry ConditionHost= alongside host-layer-only placement; ddns moves from cron to a guarded timer; package manifests and pkg-snapshot/pkg-restore replace the X11-era install_scripts/; networkmanager-dmenu added to system76 (the binding always existed, the package never did).
2.0 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| zen-tos-hold | OpenCode Zen account is hard-blocked at auth for a ToS/fraud flag — do not exercise any Zen endpoint until Connor says it is resolved |
|
As of 2026-08-28 the OpenCode Zen account was flagged by the Zen team for a
(probably faulty) terms-of-service breach, discovered while probing PRC-model
access during Phase 3c. Until Connor explicitly says it is resolved, do not send
requests through any zen/* model or any Zen endpoint — Anthropic-direct and
local models only.
Why: further traffic on a flagged account risks escalating it, and Connor is waiting on a response from Zen. He will say so when the hold lifts.
Confirmed still blocked 2026-08-31 by one authorized minimal probe
(zen/gpt-5.4-mini, 5-token cap, via LiteLLM master key). Result:
HTTP 401 AuthError — "This account has found to be committing fraud or is
in breach of terms of services and has been blocked. If you believe this
is a mistake please send an email to help@anoma.ly."
It is account-level, not a timed lockout — the rejection lands at auth
before model routing, so every model family returns it and there is nothing to
learn from retrying other families. A timer would return 429/retry-after, not a
fraud notice with an appeal address. Appeal address per their own error string:
help@anoma.ly.
Do not use Zen /v1/models as a health probe. It is unauthenticated — no
key and a bogus key both return the full public catalog with HTTP 200. It
cannot distinguish a live key from a revoked one. Only a completion can, and
completions are what the hold forbids.
How to apply: zen/* aliases still exist in config/litellm/config.yaml.
The LiteLLM virtual key used by Open WebUI (~/.config/litellm/open-webui.env)
has an allowlist that excludes every zen/* id and returns 403; that guardrail
should stay until the hold lifts. Phase 3c (PRC-model investigation) is blocked
on this. Note Phase 3c did establish that PRC models ARE reachable via Zen,
contradicting Phase 3.