Create first Playwright smoke suite for portal shell and operator surfaces

[alexeygrigorev]

Create first Playwright smoke suite for portal shell and operator surfaces

Status: pending
Tags: enhancement, portal, frontend, work-engine, testing, P1
Depends on: None
Blocks: None

Scope

Add the first cross-surface Playwright smoke coverage for the DataOps V1 operator experience. This is a smoke suite, not exhaustive E2E coverage: it should prove that the portal shell and workflow-first daily operations surfaces stay connected for the operations manager.

The suite should cover the current merged surfaces that already exist in this repo:

• frontend/ docs portal shell and Operations Home, including the left workspace sidebar, mobile top bar, Operations Home default landing behavior, task/workflow side panels, process-doc navigation, and "not connected yet" placeholder areas.
• work-engine/ browser UI and API-backed fixtures where a real authenticated task/workflow/assistant/artifact flow is needed, using the existing Playwright setup under work-engine/e2e/.
• Existing local test harness patterns in tests/docs_app/test_playwright_local_docs_flow.py, work-engine/playwright.config.js, and work-engine/e2e/global-setup.js rather than introducing an unrelated runner.

The new smoke must be stable in local and CI-like environments. It may create deterministic test data through existing APIs or local mocked /work/api responses, but it must not depend on production services, external OAuth, real Telegram/email delivery, or writing to the source repos listed in AGENTS.md.

Product Intent

This smoke protects the V1 goal in .goal-v1.md: DataOps should be a unified daily operations workspace where the operator can log in, land on what needs action today, open workflow context, complete work only with required proof, use docs in context, and avoid switching between disconnected tools.

The test should reflect the daily operations JTBD in docs/operations-manager-platform-jtbd.md:

• Start the day with one operational queue.
• Triage overdue, waiting, follow-up, and at-risk work.
• Work through today's tasks with required links/files/artifacts.
• Open process docs from task/workflow context.
• Keep assistant outputs and artifacts attached to the workflow where available.
• Show honest "not connected yet" states for unavailable inputs instead of pretending disconnected tools are live.

Acceptance Criteria

• A first Playwright smoke suite exists for the operator-facing portal shell/workflow surfaces and is named clearly enough for future smoke expansion, for example operations-smoke or equivalent.
• The smoke covers login/landing: Grace can sign in in the current authenticated work-engine UI (grace@datatalks.club / 111) and reaches the Home/dashboard surface, and the docs portal local harness lands on Operations Home by default when no folder/search/doc is selected.
• The smoke covers Operations Home in frontend/: summary counts, daily lanes (Today, Overdue, Waiting, Workflows), quick actions, recurring operations, workflow templates, goal/reference docs, and the runtime data unavailable/partially unavailable state when /work/api calls fail.
• The smoke covers workflow/task navigation from Operations Home: clicking a task opens the task panel, clicking a workflow opens the workflow detail panel, and panel close/back behavior returns the operator to Operations Home without losing the shell.
• The smoke covers proof blocking: at least one task with a missing required link/file/artifact shows a blocked next action such as Add <proof>, Attach file, or Approve an attached artifact, and completion is not presented as available until the required proof is supplied or approved.
• The smoke covers docs-in-context: a task or workflow template/reference can open the associated process document inside the portal, with the editor/rendered document view showing the expected path/title and with no full-page 404 or external-only docs handoff.
• The smoke covers assistant/artifact areas where available: the current assistant queue or bundle assistant-job area is visible when seeded in work-engine, an assistant output can be reviewed/approved in the workflow context, and an approved artifact satisfies artifact proof where the current API/UI supports that. If a specific frontend area is intentionally not connected yet, the smoke asserts the explicit "Not connected yet" state instead of fake live data.
• The smoke covers responsive shell behavior at desktop and Pixel 7-class mobile widths: desktop keeps the persistent sidebar/nav usable, mobile starts compact, opens/closes navigation, and no horizontal overflow or text overlap is present on Operations Home and the relevant task/workflow panel.
• The smoke covers "not-disconnected-tool" behavior: from a daily work item the operator can reach the workflow, proof/evidence area, process docs, and assistant/artifact area or an honest unavailable placeholder without needing to manually inspect unrelated Trello/spreadsheet/docs-list surfaces first.
• The new test data is isolated and cleaned up, or the test uses route-level stubs/local temp content that cannot pollute developer or production state.
• The implementation does not modify ../dtc-operations, ../datatasks, or ../podcast-assistant.
• Tester can verify the smoke with the commands below and capture screenshots for desktop and mobile Operations Home plus the task/workflow panel state.

Test Scenarios

Scenario: Login lands on the operator dashboard

Given: a fresh browser context without saved work-engine auth state.
When: the operator opens the work-engine app, signs in as grace@datatalks.club with password 111, and waits for navigation to complete.
Then: the sign-in form disappears, authenticated navigation is visible, the Home/dashboard route is active, and Grace's assigned-to-me dashboard controls are present.

Scenario: Docs portal defaults to Operations Home

Given: the local docs portal test harness has temp docs content, workflow-template docs, and stubbed /work/api responses.
When: the operator opens the portal root with no selected folder, search query, or document URL.
Then: the page title and library heading show Operations Home, the shell sidebar remains available, and the first screen shows operations summary, quick actions, recurring operations, daily lanes, workflow templates, and goal/reference docs rather than a raw docs list.

Scenario: Daily lanes expose next actions and proof state

Given: /work/api returns fixtures for today's task, overdue task, waiting/follow-up task, active workflow, and a task missing required proof.
When: Operations Home renders the fixtures.
Then: Today, Overdue, Waiting, and Workflows lanes show counts and meaningful cards; each card shows a next action such as Mark done, Follow up, Add Luma, Attach file, or Approve an attached artifact; missing proof is visible before completion.

Scenario: Task and workflow panels keep work in context

Given: Operations Home displays a task and workflow fixture with bundle/task IDs.
When: the operator clicks the task card and then the workflow card.
Then: the task panel and workflow detail panel open inside the same portal shell, show task/workflow title and evidence/context areas, and close without changing the operator away from Operations Home.

Scenario: Process docs open from work context

Given: a workflow template or task has an instructions/process-doc reference to a temp local content document.
When: the operator uses the process-doc action from Operations Home, task panel, or workflow template card.
Then: the document opens in the portal editor/rendered view with the expected title/path and the sidebar/tree shell still works.

Scenario: Assistant output and artifact proof are connected where available

Given: work-engine seeded data includes a bundle, a task with proofRequirement: { type: "artifact" }, an assistant job for that task/bundle, and an artifact/output requiring approval.
When: the operator opens the assistant queue or bundle detail, reviews the assistant output, approves it, and returns to the task/workflow context.
Then: the assistant job status changes to approved, the artifact is visible in the workflow context, and the task proof state reflects approved artifact evidence. Where the frontend Operations Home only has planned assistant inputs, assert the explicit Assistant Jobs / Not connected yet placeholder.

Scenario: Runtime failures are honest and non-blocking

Given: the docs portal can load content but one or more /work/api calls fail.
When: Operations Home renders.
Then: the portal shows Live work data unavailable or Live work data is partially unavailable, does not replace work data with fake items, and still shows process docs/templates as contextual help.

Scenario: Responsive portal shell remains usable

Given: desktop viewport 1280x800 and mobile viewport around 390x844.
When: the smoke visits Operations Home and opens a task/workflow panel on both viewports.
Then: desktop keeps the sidebar/nav visible, mobile uses the compact top bar/drawer behavior, navigation can be opened and closed, there is no horizontal page overflow, and key labels/buttons do not overlap.

Out of Scope

• Full regression coverage for every existing work-engine route or API endpoint.
• Redesigning Operations Home, the work-engine dashboard, auth, task model, assistant lifecycle, or artifact API beyond small testability fixes needed for this smoke.
• Real production auth, OAuth, Telegram, email, sponsor/client messages, GitHub writes, AWS deployment, or destructive production data checks.
• Replacing the existing pytest local docs harness or the existing work-engine Playwright config with a new test framework.
• Editing or importing from ../dtc-operations, ../datatasks, or ../podcast-assistant.

Dependencies

• Use existing repo-local content and fixtures where possible.
• Use the existing work-engine seed users; Grace is 00000000-0000-0000-0000-000000000001 with local password 111.
• Use existing local/CI-safe server patterns:
  • tests/docs_app/test_playwright_local_docs_flow.py for Python-driven local docs portal Playwright harness.
  • work-engine/e2e/global-setup.js and work-engine/scripts/test-server.ts for work-engine Playwright server/auth setup.
• If implementation needs new selectors, add stable semantic selectors only to the touched UI elements; do not assert brittle text order or generated IDs when a role/test id is more stable.

Verification Commands

Engineer should run the focused commands while developing:

uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app/test_playwright_local_docs_flow.py
npm --prefix work-engine run test:e2e -- --grep "operator|operations|smoke|assistant"

Tester should run the full relevant workflow for this touched surface:

uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app
npm --prefix work-engine test
npm --prefix work-engine run typecheck
npm --prefix work-engine run build
npm --prefix work-engine run test:e2e

Tester must also capture and inspect screenshots under .tmp/screenshots/ for:

• desktop Operations Home;
• mobile Operations Home;
• task panel with missing proof;
• workflow/bundle context with docs or assistant/artifact area.

[alexeygrigorev]

PM grooming complete. I rewrote the raw intake into a self-contained implementation spec for the first operator-facing Playwright smoke suite, covering login/landing, Operations Home, workflow/task navigation, proof blocking, docs-in-context, assistant/artifact areas where currently available, responsive shell checks, and honest not-connected states. I removed needs grooming because the scope, acceptance criteria, scenarios, dependencies, labels, and verification commands are now agent-ready.