docs: record e2e test requirements across remaining tasks

.claude/tasks/0016-search-commands.md

@@ -19,3 +19,4 @@ Both commands use the locator schema (`number`, `title`, `state`, `author`, `cre
 - [ ] `--state`, `--label`, `--limit`, and `--fields` work; default fields are the locator schema
 - [ ] Empty results emit the standard `<noun>[0]: (none)` empty state
 - [ ] Fixture-server tests cover both types, cross-repo results being filtered out, and the missing-query validation
+- [ ] End-to-end tests run `search issues` and `search prs` against a live Gitea instance and assert real matches are returned with the locator schema, confirming the live search-endpoint response shape and the `type`/`owner`/`q` query behavior the fixture server cannot attest to

.claude/tasks/0017-dashboard.md

@@ -20,3 +20,4 @@ Issue fetching passes `type=issues`; outside a recognizable Gitea repo the dashb
 - [ ] Issue fetches pass `type=issues` so PRs never appear in the issue block
 - [ ] Outside a Gitea repo the dashboard exits with `REPO_NOT_FOUND` and help mentioning `-R` and `--login`
 - [ ] Fixture-server tests cover both tiers, the cap-and-suffix behavior, empty states, and the no-repo error
+- [ ] End-to-end tests render the bare dashboard and `--full` against a live Gitea instance, confirming the live issue/PR list response shapes and that the computed `review` and label-aggregation fields hold against real responses — behavior the fixture server cannot attest to

.claude/tasks/0018-setup-skill-and-hooks.md

@@ -11,6 +11,7 @@ Author the Agent Skill markdown as a minimal pointer, not a command reference: f
 `setup hooks` installs a SessionStart hook via axi-sdk-js's `installSessionStartHooks()` for Claude Code, Codex, and OpenCode; the hook runs the bare binary (short dashboard tier) at session start.
 `update` shadows the SDK's built-in self-update command, failing with `VALIDATION_ERROR` and a help line pointing at the npm update command, keeping the ten-code error list intact.
 There is no postinstall script — skill and hook installation are always explicit user actions.
+These commands touch only the local filesystem, not the Gitea API, so their real-integration surface is the CLI seam against a temporary HOME rather than the live-Gitea end-to-end tier — there is no live-Gitea behavior for an e2e test to attest to here.
 
 ## Acceptance criteria
 
@@ -18,4 +19,4 @@ There is no postinstall script — skill and hook installation are always explic
 - [ ] `gitea-axi setup` installs the skill and outputs `setup: { skill, path, status }`; re-running reports `updated` or `unchanged` rather than failing
 - [ ] `gitea-axi setup hooks` registers the SessionStart hook for all three integrations via the SDK and outputs the `hooks:` block with a restart help line; managed entries are updated in place on re-run
 - [ ] `gitea-axi update` fails with `VALIDATION_ERROR` (exit 2) and the npm update help line; the SDK's `UPDATE_ERROR` never surfaces
-- [ ] Tests cover the setup idempotency states and the update shadow (hook installation verified against a temp home directory)
+- [ ] Integration tests drive `setup`, `setup hooks`, and `update` at the CLI seam against a temporary HOME, asserting the real skill file and the three managed hook configs are written and updated in place, and covering the setup idempotency states and the update shadow (this temp-HOME filesystem tier is the applicable real-integration test; these commands make no Gitea API calls, so there is no live-Gitea e2e case)

.claude/tasks/0020-npm-distribution.md

@@ -9,6 +9,7 @@ Publish readiness for the unscoped `gitea-axi` npm package.
 Package metadata (name, description, repository, license, engines for Node 20+, ESM), the `gitea-axi` bin entry, and the bundled Agent Skill file included in the published artifact.
 No postinstall script — the install delivers the CLI binary only, and skill installation stays behind the explicit `setup` command.
 Verify the packed artifact: a global install from the packed tarball yields a working binary whose `setup` finds the bundled skill.
+This tarball-and-global-install check is the applicable real-integration surface for this slice; distribution touches no Gitea API, so there is no live-Gitea end-to-end case — the packaging smoke test below stands in its place.
 
 ## Acceptance criteria
 

.claude/tasks/0021-body-field-truncation-ruling.md

@@ -19,6 +19,7 @@ Decide, then make the spec and the code agree:
 - If `--fields body` is genuinely exempt, amend Principle 3 to carve out the exemption explicitly and say why, so the next slice offering a `body` field does not have to re-derive it.
 
 Whichever way it goes, `issue list`, `issue create`, and any later command exposing `body` via `--fields` must behave the same.
+The ruling is verified at the fixture/unit tier only: body truncation is deterministic string processing over a body the CLI already holds, with no live-Gitea response semantics for an end-to-end test to attest to, so no e2e case is warranted here.
 
 ## Acceptance criteria