The test overwrote ai_api_key with a marker and then restored it to ""
rather than to its previous value, so every run of the integration suite
silently wiped the AI provider key. Symptom appears much later and looks
nothing like a test problem: AI features quietly stop working.
Captures the existing value first and restores it in a finally block, so a
failed assertion cannot leave the marker in place either. Deletes the
record instead when the test created it.
The suite runs against the shared instance — there is no separate test
database — so anything it touches, it must put back exactly.
feat(board): give the owner both a quick box and Plan with AI
The Phase 4 spec made the intake wizard client-facing only, reasoning that
the developer creates cards directly. That was wrong about how he wants to
work. The quick box stays the default for lines he already understands;
Plan with AI runs the same interview for work that is genuinely unformed.
Hidden entirely when no provider is configured.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three tests cover the storage and access boundary:
- A client manager cannot list the settings collection at all (rules are
superuser-only — verified by the rejection, not by silent skip).
- The settings page HTML returned to the owner does not contain the key
value, even when the key is freshly set to a unique sentinel.
- A client manager gets 404 on /admin/settings (admin layout gates on
role, not on session presence).
helpers.ts gained ownerEmail / ownerPassword — needed by the settings test
and reusable for any owner-only integration test going forward.
