fix: honor --incognito by disabling the experience tracker (plan 009)

[DavertMik]

Implements plan 009 (plans/009-*.md) as a standalone PR off main.

explorbot --incognito ("run without recording experiences") flowed CLI → ExplorBot → Explorer, and Explorer called new StateManager({ incognito }) — but StateManager's constructor took no parameters, so the flag was silently dropped and the ExperienceTracker stayed enabled. Incognito runs read and wrote ./experience like normal runs.

Fix

Thread incognito into the StateManager constructor and pass { disabled: options.incognito } to ExperienceTracker (which already supports disabled). Argument-less constructions keep today's enabled behavior via options.disabled ?? false.

Verification

bun test tests/unit → 757 pass, 0 fail (incl. 2 new incognito tests); bunx tsc --noEmit → 723.

Note

This is the clean re-do of the mistakenly-stacked #78. It touches only the StateManager constructor signature + the ExperienceTracker line; plan 010 (#separate PR) touches the same constructor to add knowledgeTracker, so whichever of the two merges second needs a one-line constructor merge ({ incognito?, knowledgeTracker? }). Both are independently valid off main.

🤖 Generated with Claude Code

[DavertMik]

Closing per request — the incognito fix isn't wanted. Reopen if that changes.

[github-actions]

Explorbot Self-Regression

Commit 7ba1130 · run

Scenario	Result	Attempts	Duration
basic (native)	PASS	1/3	6m
experience: control	OK — failed as expected	1/1	1m
experience: seeded	PASS	2/3	3m

Attempt details

• basic (native) attempt 1 — PASS: login evidence: PASS (post-login plan=true, post-login research=true); research: PASS (files=7, wellFormed=true, keywords=7/3); scenarios: PASS (tests=6/5, features=4/3); tests passed: PASS (5 passed, 0 failed (reporter: 5 passed, 0 failed))
• experience: control attempt 1 — PASS: control: OK — failed as expected (0 passed, 1 failed)
• experience: seeded attempt 1 — FAIL: seeded: FAIL (0 passed, 1 failed)
• experience: seeded attempt 2 — PASS: seeded: PASS (1 passed, 0 failed)

---

Session analysis — basic (native):

Session Analysis

The Issues list page was explored across 5 test scenarios covering navigation to new issue creation, filtering by labels, searching issues, filtering by status, and navigating to issue details. All core flows completed successfully from a product standpoint, though some automation execution issues occurred during test execution.

Coverage

• Pages: /issues, /issues?new=1, /issues?label=1, /issues?q=Export, /issues?status=open, /issues/4
• Features: New Issue form, Label filtering, Search filtering, Status filtering, Issue detail navigation

What works

• New Issue form — ET-1 Navigate to New Issue form from Issues page
• Label filtering — ET-2 Filter issues by label 'bug'
• Search filtering — ET-3 Search for issues using search textbox
• Status filtering — ET-4 Filter issues by status
• Issue detail navigation — ET-5 Navigate to issue detail view

Execution Issues

• ET-2 Filter issues by label 'bug' — multiple attempts to click Cancel button on modal failed, test proceeded anyway