Release v3.35.1

.changelogs/v3.35.1.md

@@ -0,0 +1,25 @@
+# Release v3.35.1
+
+Released: 2026-08-27
+
+## Highlights
+
+- **`/do:next` works again on GitLab.** Its issue-claiming flow shelled out to `glab api ... --jq`, but plain `glab api` — unlike the `glab issue` / `glab mr` subcommands — has no `--jq` flag and exits with `Unknown flag: --jq`. Every `glab api` call now pipes to the standalone `jq` binary instead, so claiming and updating a GitLab issue no longer fails at the first API call.
+- **`--self` can no longer be silently disarmed on GitLab.** The login is now resolved in two checked steps rather than one pipeline. A pipeline reports only `jq`'s exit status, and `jq -r .username` exits 0 on empty input — so a failed `glab api user` used to leave the login empty, turning the `--self` author filter into a no-op and the claim marker into a no-op assign that still looked like success. Both sites now fail closed.
+- **`jq` is checked before the first `glab api` call — in issue mode only.** Piping to the standalone binary makes jq a hard dependency of the GitLab *issue* path; the probe sits at the top of that phase with an install hint, so a GitLab repo working a PLAN.md backlog (which never calls plain `glab api`) is not newly required to install jq.
+- **The native blocked-by lookup no longer fails open on GitLab.** A pipeline reports only jq's exit status, and jq succeeds on empty input, so a Links-API outage was indistinguishable from "this issue has no native blockers" — and the picker could claim a dependent ahead of its blocker. A failed lookup is now UNRESOLVED (fall back to the body convention, and say so), never unblocked.
+
+## Fixed
+
+- `commands/do/next.md`: replaced `glab api --jq <filter>` with `glab api ... | jq <filter>` across all four call sites. Caught live while dogfooding against a real GitLab issue.
+- `commands/do/next.md`: the `--self` list filter and the Phase 2 claim marker resolve the GitLab login via `glab api user` → `jq -er .username` with both exit statuses checked **and** the result guarded on non-empty. `jq -e` fails only on `null`/`false`, so a `{"username":""}` response slipped through it — and an empty login means `--author ""`, which glab reads as no author filter at all.
+- `commands/do/next.md`: the GitLab issue-mode phase probes `command -v jq` before its first plain `glab api` call — and the swarm preconditions carry the same probe, since swarm replaces Phases 1–7 and would otherwise skip it while still running the native blocked-by check.
+- `commands/do/next.md`: the GitLab native blocked-by lookup captures `glab api`'s response and status before filtering it, so an API failure degrades to the body convention instead of reading as "not blocked".
+
+## Added
+
+- `test/glab-jq-contract.test.js`: contracts pinning that no plain `glab api` call carries `--jq`, that the login resolution stays two-step with a non-empty guard at both sites, that the blocked-by lookup keeps glab's status separate from jq's, and that the `jq` probe covers both the issue-mode and swarm paths without leaking into the shared pre-flight.
+
+## Full Changelog
+
+**Full Diff**: https://github.com/atomantic/slashdo/compare/v3.35.0...v3.35.1