A GitHub remote should not be a precondition for Taskless

[thecodedrift]

Summary

rule create's remote generation path requires a GitHub origin remote. Today that requirement is enforced as a precondition on the command, so a project without a GitHub remote (or without git at all) gets no rule authoring path from the remote tier, and the failure reads as an auth problem rather than a capability boundary.

A GitHub remote should not be a precondition for using Taskless. The correct behavior is narrower: with no GitHub-based remote, we remove the ability to do remote rule generation, and nothing else. Remote rule generation, runtime rules, and third-party services need a verifiable org identity. Local authoring does not.

Reported example

From a field report (Linear TSKL-291): onboarding an Obsidian vault of markdown notes (clippings, contacts, meeting logs). Not a git repository at all.

$ git status
fatal: not a git repository

The user followed the documented route -> static/remote recipes and had no available path:

• the static (ast-grep) path was blocked separately, because the bundled ast-grep has no markdown support (Upgrade ast-grep from 0.41.0 (post-0.11.0) #162)
• the remote path was foreclosed by this precondition, independent of plan, login, or auth state

Either blocker alone is survivable. Together they mean a whole class of project (notes vaults, docs repos, any non-git or non-GitHub tree) has no way to author a rule.

Where it lives

resolveIdentity (packages/cli/src/auth/identity.ts:25) resolves the token, then the repository URL, then the org subject. The repository URL comes from git remote get-url origin (packages/cli/src/util/git-remote.ts:12), and a non-GitHub remote is rejected as well:

Could not determine repository URL from git remote. Ensure your repository has an 'origin' remote pointing to GitHub.
Unsupported git remote URL: "<url>". Only GitHub repositories (github.com) are supported.

So this affects three populations, not one:

1. not a git repository
2. a git repository with no origin
3. a git repository whose origin is not GitHub (GitLab, Gitea, self-hosted)

taskless help rule create documents "Repository has a GitHub origin remote" in its precondition list, with NO_GITHUB_REMOTE as a named error code.

What to decide

The requirement itself is legitimate where identity is legitimately required. The question is scope and framing:

• Which tiers actually need a verifiable org? Remote rule generation and runtime rules do, as do third-party service integrations. Local static authoring, verify, test, and check do not.
• Precondition or capability boundary? A precondition blocks the command. A capability boundary lets the command run and reports that one tier is unavailable, the way an unauthenticated user is told to log in rather than being told the product does not work.
• What should route say? Today the recipes do not assume a code repo, which is why this lands as a surprise late in the flow rather than as a known constraint up front.

Acceptance

• A project with no GitHub remote can complete every non-remote authoring path without hitting a GitHub precondition
• The remote tier reports its unavailability as a capability boundary naming the reason, distinct from an auth failure
• route states the constraint before an agent invests in a path that cannot complete
• The three populations above are covered by tests, including a non-GitHub origin

Refs #162
Refs TSKL-291