@klok-integration/cli 0.7.248 → 0.7.269

package/assets/agents/skills/klok-solution/SKILL.md

@@ -30,10 +30,14 @@ shared platform service) in `klok/integration-solutions`.
    issue, never to ignore.
 3. **Read the design.** The solution document and any design page next to it, then each project's `klok-docs/`
    (`klok docs read <doc-id>`, `klok docs id <repo path>` gives the id).
-4. **A new solution gets an id and a document before code.** Take the id from the code, not the next free
-   number: grep the integration repositories, pushed branches included, and run `klok solutions validate`. Write
-   `README.md`, `solution.meta.json` (`generatedBy: "manual"`) and, when the details do not fit, a design page next
-   to it, in a worktree of the registry. The sections are listed in the registry README.
+4. **A new solution gets an id and a document before code.** The merge request that adds the solution's folder to
+   the registry is the allocation: `klok solutions new "<name>" --dry-run`, then without `--dry-run`, opens it from a
+   worktree of the registry with the next free number (`klok solutions next` says why that one: the registry, its
+   history and open merge requests, and the route classes on every branch). Never choose another number, and never
+   reuse one, not even a removed solution's. The folder starts `"status": "reserved"`; write `README.md`, the
+   describing fields of `solution.meta.json` and, when the details do not fit, a design page next to it, and set the
+   status to `active`. The sections are listed in the registry README. `klok solutions validate --base origin/main`
+   checks the change against the registry's history and its open merge requests.
 5. **Reuse before building.** Look for an existing solution or platform capability first: tasks and the task API
    (KLK002), the ODL, the AI services (KLK003), mail (KLK006), the claim check, datamodels in the catalog. A
    capability that needs a change to serve the solution is *reused, slight change*, with its own merge request in
@@ -81,6 +85,9 @@ shared platform service) in `klok/integration-solutions`.
 ## Things that are always wrong
 
 * Code for a new solution before its document exists, or a route id whose prefix is not a registered solution.
+* A solution number that is not the next free one (`klok solutions next`), or one used before.
+* Deleting a solution's folder in a merge request: a solution that stops running gets `"status": "retired"`; only a
+  platform admin removes one, on `main`, and its number stays spent.
 * A leg in code that its solution document does not name, or a document that names a leg as built that is not.
 * Reusing a leg and sequence (`KLK002A11`) for a second route.
 * Integration logic in a Python or TypeScript client, or in an external engine, without a `[TACTICAL]` entry.

package/assets/agents/skills/klok-worktree/SKILL.md

@@ -36,7 +36,9 @@ basename, never put the worktree inside `.claude`, inside the canonical checkout
    you. Keep the existing project rules; this skill does not replace them.
 3. **Inspect, do not touch.** `git -C <canonical> status --short`, `git -C <canonical> worktree list --porcelain`
    and the canonical branch. Never `stash`, `reset`, `clean`, `checkout` or `switch` there; the only update of a
-   canonical checkout is `klok sync pull`, which fast-forwards it or reports why it cannot. Uncommitted changes in
+   canonical checkout is `klok sync pull`, which fast-forwards it or reports why it cannot. When it reports that the
+   checkout's GitLab project moved, the move and the `git worktree repair` it lists are the person's: hand them over,
+   and base the worktree on the project at its new path. Uncommitted changes in
    the canonical checkout are not a blocker; the worktree starts from committed history. If the task depends on
    those changes, say so and ask for a handoff instead of moving them.
 4. **Choose the base.** Fetch the remote and resolve its default branch from the remote HEAD