Context
We own the remoteclaw.org domain, not remoteclaw.ai. The fork has accumulated .ai URL references that point to domains we do not control. A recent sync (PR #2379) fixed docs.remoteclaw.ai → docs.remoteclaw.org in 16 files but these additional references were out of scope for that cleanup.
Files with remaining .ai references
src/channels/registry.ts: const WEBSITE_URL = "https://remoteclaw.ai";
src/channels/plugins/onboarding/telegram.ts (two occurrences): "Website: https://remoteclaw.ai"
src/wizard/onboarding.finalize.ts:~567: "https://remoteclaw.ai/showcase"
src/slack/monitor/events/interactions.test.ts (two occurrences): team@remoteclaw.ai
docs/security/README.md, docs/security/CONTRIBUTING-THREAT-MODEL.md, docs/security/THREAT-MODEL-ATLAS.md: trust.remoteclaw.ai
docs/install/docker.md:~176: org.opencontainers.image.url=https://remoteclaw.ai
docs/platforms/raspberry-pi.md, docs/help/faq.md, docs/reference/RELEASING.md: curl -fsSL https://remoteclaw.ai/install.sh
apps/ios/fastlane/metadata/en-US/support_url.txt: https://docs.remoteclaw.ai/platforms/ios — becomes App Store-visible "Support" URL
Problem severity
- docker image label:
docker.md:176's image.url=.ai + image.documentation=.org (from the earlier cleanup) creates an image with two inconsistent labels
- fastlane support_url: if the fork ever submits iOS builds to the App Store, users clicking "Support" hit a domain we don't control
- install scripts:
install.sh references assume remoteclaw.ai hosts the script; that domain doesn't serve anything
- trust.remoteclaw.ai: threat model documents reference a security-disclosure endpoint that does not resolve
Scope
Replace every .ai URL with the correct .org equivalent. Where a .ai path is speculative (e.g., /showcase, /install.sh), decide whether to (a) stand up the path on .org, (b) remove the reference, or (c) point elsewhere (GitHub release asset, etc.).
Acceptance criteria
Non-goals
- Does not change app behavior, only URLs
- Does not claim the
.ai TLD for the fork
Context
We own the
remoteclaw.orgdomain, notremoteclaw.ai. The fork has accumulated.aiURL references that point to domains we do not control. A recent sync (PR #2379) fixeddocs.remoteclaw.ai→docs.remoteclaw.orgin 16 files but these additional references were out of scope for that cleanup.Files with remaining
.aireferencessrc/channels/registry.ts:const WEBSITE_URL = "https://remoteclaw.ai";src/channels/plugins/onboarding/telegram.ts(two occurrences):"Website: https://remoteclaw.ai"src/wizard/onboarding.finalize.ts:~567:"https://remoteclaw.ai/showcase"src/slack/monitor/events/interactions.test.ts(two occurrences):team@remoteclaw.aidocs/security/README.md,docs/security/CONTRIBUTING-THREAT-MODEL.md,docs/security/THREAT-MODEL-ATLAS.md:trust.remoteclaw.aidocs/install/docker.md:~176:org.opencontainers.image.url=https://remoteclaw.aidocs/platforms/raspberry-pi.md,docs/help/faq.md,docs/reference/RELEASING.md:curl -fsSL https://remoteclaw.ai/install.shapps/ios/fastlane/metadata/en-US/support_url.txt:https://docs.remoteclaw.ai/platforms/ios— becomes App Store-visible "Support" URLProblem severity
docker.md:176'simage.url=.ai+image.documentation=.org(from the earlier cleanup) creates an image with two inconsistent labelsinstall.shreferences assumeremoteclaw.aihosts the script; that domain doesn't serve anythingScope
Replace every
.aiURL with the correct.orgequivalent. Where a.aipath is speculative (e.g.,/showcase,/install.sh), decide whether to (a) stand up the path on.org, (b) remove the reference, or (c) point elsewhere (GitHub release asset, etc.).Acceptance criteria
grep -r "remoteclaw\.ai" .returns only license/attribution references or migration-compat shimstrust.remoteclaw.aireferences either resolve or are replaced with current channelsNon-goals
.aiTLD for the fork