fix(agent): carry the new codes into improve-rule, and correct four contract gaps

From review of #190. All five findings verified against the code before acting;
all five were real, and one was my own error.

`improve-rule.txt` was left on the old contract. `rule improve` goes through the
same service path as `rule create` and raises the same three codes — the new
`error-envelope` cases already assert that — but its recipe still listed "a
GitHub origin remote" as a precondition and documented only `NO_GITHUB_REMOTE`.
An agent following it in any no-remote population got an undocumented code and
no guidance, which is the exact failure this change set out to remove from
`rule create`. It now carries the same precondition check, the same three codes,
and the same note that `auth login` does not fix it.

The test that should have caught it named one recipe, so it could not. It is now
`it.each` over both, which is what makes the omission impossible to repeat.

`cli-rule-routing`'s spec said `route` reads the repository URL from `auth`. It
reads `ghOwner` from `info`; the `auth` wording predates moving those fields and
was never updated, so one scenario asserted the opposite of what was built and
of what every other spec in the change says. Corrected in the live spec and in
the archived delta.

Both touched recipes skipped their topic version bump, which `cli-agent`'s spec
requires on a meaningful change. `route` gained a whole step and a renumbering;
`create-remote-rule` gained a precondition section and three error rows.
Bumped to v3 and v2, and `improve-rule` with them.

`create-remote-rule` claimed four distinguishable causes. The throwing path
distinguishes three: the probe that would separate "git not installed" from
"not a git repository" is itself a `git` call, so a missing binary reports
`NOT_A_GIT_REPOSITORY`. Rather than claim a distinction the code cannot make,
the recipe now says so and tells the reader to check `PATH` when the user
insists the directory is a repository. `resolveRepositoryContext` is unaffected:
it never throws and reports `[unknown]` whatever the cause.

`resolveIdentity`'s docstring still named `NO_GITHUB_REMOTE` as the failure it
raises.

Refs #179

Author: theCodeDrift

openspec/changes/archive/2026-08-26-remote-tier-capability-boundary/specs/cli-rule-routing/spec.md

@@ -18,4 +18,4 @@
 #### Scenario: The availability test has one source
 
 - **WHEN** `route` determines whether remote generation is available
-- **THEN** it SHALL rely on the repository URL reported by `auth` rather than re-deriving the remote independently
+- **THEN** it SHALL rely on the `ghOwner` reported by `info` rather than re-deriving the remote independently

openspec/specs/cli-rule-routing/spec.md

@@ -331,4 +331,4 @@ unusable where the engine's platform binary did not resolve.
 #### Scenario: The availability test has one source
 
 - **WHEN** `route` determines whether remote generation is available
-- **THEN** it SHALL rely on the repository URL reported by `auth` rather than re-deriving the remote independently
+- **THEN** it SHALL rely on the `ghOwner` reported by `info` rather than re-deriving the remote independently

packages/cli/src/agent/create-remote-rule.txt

@@ -1,4 +1,4 @@
-# Topic: create-remote-rule     (CLI v%(CLI_VERSION)s / topic v1)
+# Topic: create-remote-rule     (CLI v%(CLI_VERSION)s / topic v2)
 
 ## You are here
 This is `create-remote-rule`. It helps you have the Taskless service
@@ -48,8 +48,13 @@ is advisory; this is the point of use.
 
 **`auth login` does not fix it.** No GitHub owner is a property of the
 project, not the session, so do not send the user to log in for it. The
-four causes are: not a git repository, no `origin` remote, an `origin`
-that is not GitHub, and no git installed.
+causes are: not a git repository, no `origin` remote, an `origin` that is
+not GitHub, and git not being installed at all. The first three each have
+their own error code; a missing `git` binary cannot be told apart from
+the first, because the probe that would distinguish them is itself a
+`git` call, so it reports `NOT_A_GIT_REPOSITORY`. If the user says the
+directory *is* a repository, check whether `git` is on their `PATH`
+before believing the code.
 
 ## Cost, and when this path is right
 

packages/cli/src/agent/improve-rule.txt

@@ -1,4 +1,4 @@
-# Topic: improve-rule     (CLI v%(CLI_VERSION)s / topic v3)
+# Topic: improve-rule     (CLI v%(CLI_VERSION)s / topic v4)
 
 ## Goal
 Iterate on an existing Taskless rule. The CLI submits the user's
@@ -12,7 +12,12 @@ If the user wants the local-only flow (no API call), fetch
 
 ## Preconditions
 - User is logged in.
-- Repository has a GitHub origin remote.
+- The project has a GitHub owner. Improvement runs through the same
+  service path as generation, so it carries the same constraint. Check
+  `ghOwner` from `%(TASKLESS_CLI)s info --json`: if it is the literal
+  `[unknown]`, stop and say the tier is unavailable rather than
+  submitting. `auth login` does not fix it — no GitHub owner is a
+  property of the project, not the session.
 - The target rule exists at `.taskless/rules/sg/<id>/<id>.yml`.
 - The rule has metadata at `.taskless/rule-metadata/<id>.yml` (the
   `ticketId` is required by the iterate endpoint). If metadata is
@@ -110,7 +115,10 @@ When `--json` is set, failures emit `{ ok: false, code, message }`:
 | code                     | meaning                             | fix                                           |
 |--------------------------|-------------------------------------|-----------------------------------------------|
 | `AUTH_REQUIRED`          | not logged in                       | fetch `%(TASKLESS_CLI)s agent auth`           |
-| `NO_GITHUB_REMOTE`       | no GitHub origin remote             | tell the user; we cannot proceed              |
+| `NO_GITHUB_REMOTE`       | no GitHub origin remote             | retained for compatibility; treat as below    |
+| `NOT_A_GIT_REPOSITORY`   | not a git repository                | tell the user; `auth login` cannot fix it     |
+| `NO_ORIGIN_REMOTE`       | git repository, no `origin`         | tell the user; `auth login` cannot fix it     |
+| `UNSUPPORTED_REMOTE_HOST`| `origin` is not GitHub              | tell the user; `auth login` cannot fix it     |
 | `INVALID_INPUT`          | `--from` JSON failed validation     | re-read input schema, fix, retry              |
 | `RULE_NOT_FOUND`         | metadata missing for the given rule | use anonymous variant or recreate via create  |
 | `NETWORK_ERROR`          | API submit/poll failed              | report and suggest retry                      |

packages/cli/src/agent/route.txt

@@ -1,4 +1,4 @@
-# Topic: route     (CLI v%(CLI_VERSION)s / topic v2)
+# Topic: route     (CLI v%(CLI_VERSION)s / topic v3)
 
 ## Goal
 Turn "write me a rule that…" into one command to run. This is the front

packages/cli/src/auth/identity.ts

@@ -23,9 +23,11 @@ export interface Identity {
  * - repositoryUrl: inferred from `git remote get-url origin`
  *
  * Throws a `CLIError` carrying a stable `CLIErrorCode` if auth is missing
- * (`AUTH_REQUIRED`) or the repository URL cannot be resolved
- * (`NO_GITHUB_REMOTE`). Read the code off the error with
- * `identityFailureCode`; never re-derive it from the message.
+ * (`AUTH_REQUIRED`) or the repository URL cannot be resolved, in which case
+ * the code names which population the project is in:
+ * `NOT_A_GIT_REPOSITORY`, `NO_ORIGIN_REMOTE`, or `UNSUPPORTED_REMOTE_HOST`.
+ * Read the code off the error with `identityFailureCode`; never re-derive it
+ * from the message.
  */
 export async function resolveIdentity(cwd: string): Promise<Identity> {
   const token = await getToken(cwd);

packages/cli/test/agent-extensions.test.ts

@@ -419,21 +419,37 @@ describe("the GitHub-owner constraint is guarded twice", () => {
     expect(result.stdout).toContain("stop here");
   });
 
-  it("the remote recipe documents every code the populations raise", async () => {
-    const result = await runCli(["agent", "create-remote-rule", "-d", cwd]);
-    for (const code of [
-      "NOT_A_GIT_REPOSITORY",
-      "NO_ORIGIN_REMOTE",
-      "UNSUPPORTED_REMOTE_HOST",
-      // Retained for compatibility, so it must stay documented too.
-      "NO_GITHUB_REMOTE",
-    ]) {
-      expect(result.stdout).toContain(code);
-    }
-  });
-
   it("the remote recipe does not send the user to auth login for it", async () => {
     const result = await runCli(["agent", "create-remote-rule", "-d", cwd]);
     expect(result.stdout).toContain("`auth login` does not fix it");
   });
+
+  // `rule improve` goes through the same service path and raises the same
+  // three codes, so its recipe carries the same contract. The first version of
+  // this change updated only `create-remote-rule`, and nothing caught it: the
+  // test above names one recipe, so it could not.
+  it.each(["create-remote-rule", "improve-rule"])(
+    "%s documents every code the populations raise",
+    async (topic) => {
+      const result = await runCli(["agent", topic, "-d", cwd]);
+      expect(result.exitCode).toBe(0);
+      for (const code of [
+        "NOT_A_GIT_REPOSITORY",
+        "NO_ORIGIN_REMOTE",
+        "UNSUPPORTED_REMOTE_HOST",
+        // Retained for compatibility, so it must stay documented too.
+        "NO_GITHUB_REMOTE",
+      ]) {
+        expect(result.stdout).toContain(code);
+      }
+    }
+  );
+
+  it.each(["create-remote-rule", "improve-rule"])(
+    "%s says auth login does not fix a missing owner",
+    async (topic) => {
+      const result = await runCli(["agent", topic, "-d", cwd]);
+      expect(result.stdout).toMatch(/`auth login` (does not|cannot) fix/);
+    }
+  );
 });