im-dream: Skill for Codex

Ink-Dream Playwright QA

Use the repository-local @playwright/test runtime. Select the real-business or technical-isolation lane explicitly. Produce assertions and evidence, not screenshot-only approval.

Read references/project-workflow.md before starting a browser run. Read its SubAgent fixture section only when testing SubAgent projections or timelines.

For authenticated real-business QA, read references/auth-checkpoints.md before login or session recovery. Find the prior successful entry, identity and credential source first; record a new secret-free checkpoint immediately after success. A rejected product password does not invalidate a separately saved Admin credential or an existing management session.

Test execution agent

Delegate bounded provider-free, isolated, mocked-browser, source/unit, and visual-regression execution to the luna_test_runner custom agent. It is configured for gpt-5.6-luna, high reasoning, and Fast mode. Give it the exact spec/command, worktree, expected evidence, owned ports/data, and cleanup scope; wait for its command receipts before accepting results.

Keep real-user or real-model business acceptance, production mutation, migration/destructive work, approvals, diagnosis, and implementation in the primary agent. If the runner cannot access the required browser or runtime, report a harness blocker; do not silently replace the requested lane. Apply the full routing contract from $luna-test-stage when available.

Non-negotiable rules

• Run technical Playwright stages from frontend/ with the installed @playwright/test. For primary real-business operations, honor an explicitly selected browser plugin and its controller; do not replace its profile or saved-session state with a standalone browser.
• Inspect git status --short first. Preserve unrelated changes and remove only artifacts created by the current QA run.
• Use an isolated database and absolute workspace root only for explicitly technical, provider-free, destructive, migration, or fault-injection tests. For user-requested real business or real-model QA, use the named existing local account/Run and normal Dream/Admin/Gateway/PostgreSQL path. Never clone real data or substitute a shadow account, Deck, ledger, or Admin instance.
• Treat ports 5173 and 8765 as owned only after resolving their listener PIDs. Never kill an unidentified process.
• Register API, console, page-error, and request-failure listeners before navigation.
• Before starting any Dream browser, model, or mutation step, write a Dream business concept and impact brief. Define Project, Episode, canonical Artifact, Run-private .dream publication, after-turn Hook, PostgreSQL/API projection, and final UI consumer for the scenario. Then mark every affected fact as changes, must remain unchanged, or not in scope. A test without this brief has no trustworthy expected result and must not start.
• Write business E2E scenarios as normal human journeys through visible UI. API calls may stage isolated prerequisites or verify persisted facts, but must not replace the meaningful user interaction under test.
• Real Agent dialogue must use only language a user can derive from the page and conversation. Do not put internal IDs, absolute paths, filenames, .dream contracts, Hook instructions, canonical terminology, or exact tool commands in the user's message. Test code may discover stable IDs and paths after the turn for assertions and confirmation safety, but must never teach them to the model through the composer.
• A business mutation is complete only when the whole consumer chain is proven: visible request → shared Thread/Agent action → canonical file → successful after-turn Hook → private .dream publication when applicable → PostgreSQL projection → public API → final visible consumer page. A file SHA, assistant sentence, HTTP health check, or screenshot alone is not acceptance.
• Treat visible Agent/Thread termination as the business terminal. Once the UI shows that the Agent has stopped, immediately validate required output and fail if it is incomplete; process, port, SSE reconnect, or HTTP health alone must never justify continued business polling.
• Handle required tool confirmations through the visible UI as part of the human journey. Approve only case-specific allowlisted operations after the test identifies the displayed tool; fail on unknown, Bash, network, or other unreviewed confirmations instead of silently approving or polling behind them. AskUserQuestion answers must come from explicit scenario input.
• Keep headed browser windows within the current desktop using an explicit bounded outer window and deterministic content viewport. Never use zoom, CSS scaling, maximization, or hidden panels to conceal a responsive defect; require zero document-level horizontal overflow and keep the scenario's heading, primary action, and blocking dialogs inside the visible viewport.
• Prefer roles, labels, titles, and test ids. Do not use forced clicks to make a test pass; use keyboard activation only when intentionally validating or bypassing the known Writing overlay.
• Wait for visible state and known transitions. Do not replace readiness checks with arbitrary long sleeps.
• Verify behavior with assertions before taking screenshots.
• Stop only services started by the QA run. Remove its temporary technical data, but preserve real business Run/Thread/Gateway/Admin records unless the user explicitly requests cleanup.