Productize team import and lock board lifecycle with E2E

.dockerignore

@@ -0,0 +1,18 @@
+node_modules
+.git
+.DS_Store
+.env
+.factory
+dist
+packages/*/dist
+packages/server/src/*.js
+packages/server/src/*.js.map
+packages/server/src/*.d.ts
+packages/server/src/*.d.ts.map
+packages/server/prisma/*.js
+packages/server/prisma/*.js.map
+packages/server/prisma/*.d.ts
+packages/server/prisma/*.d.ts.map
+.tmp
+playwright-report
+test-results

.env.example

@@ -1,3 +1,3 @@
-DATABASE_URL=YOUR_DATABASE_URL_HERE
-AUTH_TOKEN=YOUR_AUTH_TOKEN_HERE
+DATABASE_URL=postgresql://involute:involute@127.0.0.1:5434/involute?schema=public
+AUTH_TOKEN=changeme-set-your-token
 PORT=4200

.factory/library/son-validation-dataset-restore.md

@@ -0,0 +1,17 @@
+# SON validation dataset restore
+
+- Purpose: restore the imported `SON` dataset needed by CLI/web/API cross-surface validation (`VAL-CROSS-007`, `VAL-CROSS-015`) without disturbing the seeded `INV`/`APP`/`VAL` validation data.
+- Command: `cd /Users/chris/workspace/Involute/packages/server && pnpm setup:son-validation`
+- Equivalent manifest command: `.factory/services.yaml` → `commands.restore_son_validation_data`
+- Source export: `/Users/chris/workspace/Involute/.factory/validation/import/user-testing/tmp/import-export-flow/export`
+- What it does:
+  - re-runs the import pipeline against the saved SON export fixture (idempotent),
+  - then runs the existing web-ui validation setup so `INV`, `APP`, and `VAL` fixtures remain available,
+  - leaves existing imported SON issues/comments intact on reruns.
+- Expected result after a successful run:
+  - `SON` team exists with ~404 imported issues,
+  - CLI `issues list --team SON --json` returns imported issues,
+  - API queries for `team.key = SON` return imported rows,
+  - `INV` still contains the repeatable web-ui validation cards and `VAL` remains empty.
+- Known caveat:
+  - CLI `issues show SON-363` can still fail until the separate pre-existing CLI identifier lookup regression (current workspace baseline failure in `packages/cli/src/commands/issues.test.ts`) is fixed; list-based SON verification remains valid meanwhile.

.factory/library/user-testing.md

@@ -17,6 +17,8 @@
 - **Setup:** Start API server first, then web dev server (`cd packages/web && PORT=4201 npx vite --port 4201`)
 - **Entry point:** `http://localhost:4201`
 - **Prerequisite:** API server must be running and healthy
+- **Preferred team for board validation:** Use the seeded `INV` team for canonical six-column workflow checks. Imported teams like `SON` are valid for import-consistency checks, but may not expose the exact six-state workflow needed for full board/dnd coverage.
+- **Validation data note:** Before manual board/dnd checks, confirm the selected team actually has visible issues. If the board is empty, switch to a team with imported issues (for example `SON`) or create a fresh issue through the UI first, then perform drag/detail/comments validation on that card.
 
 ### 3. CLI
 - **Tool:** terminal commands (Execute tool)
@@ -90,3 +92,19 @@
 - Evidence: save raw GraphQL request/response JSON for each checked assertion.
 - Concurrency: up to 3 concurrent validators if they verify disjoint imported fixtures.
 
+## Flow Validator Guidance: Web UI
+
+- Surface boundary: use only the live browser app at `http://localhost:4201` and the paired local API at `http://localhost:4200/graphql` for cross-checks.
+- Isolation rule: each validator must use its assigned `agent-browser --session` name and avoid shared-service teardown or disruptive environment changes while other validators are running.
+- Data isolation: prefer creating uniquely prefixed issues/comments for the assigned validator (`<group>-<timestamp>`) and re-query those exact records via GraphQL instead of relying on global counts.
+- **Team selection (CRITICAL)**: Use the **INV** team (key="INV") for six-column board validation. INV has 6 workflow states: Backlog, Ready, In Progress, In Review, Done, Canceled. Do NOT use APP team which has only 2 states. Query `teams(filter: { key: { eq: "INV" } })` to resolve the INV team ID.
+- **Data seeding before board tests**: Before testing board/dnd/drawer assertions, create 3-5 test issues via `issueCreate` mutation against the INV team in various states. Use uniquely-prefixed titles like `ut2-<group>-test-1`. This ensures the board is not empty and cards are available for drag/click/edit testing.
+- **Stable DnD automation targets**: Use the dedicated drag handle selectors `data-testid="issue-drag-handle-<IDENTIFIER>"` on cards and target destination columns via `data-droppable-state-id="<STATE_ID>"` / state-based board column selectors. Do not rely on generic accessibility refs alone for drag validation.
+- **Labels are seeded**: The database contains 10+ labels (task, epic, spec, Feature, Bug, etc.). If `issueLabels` query returns empty, re-seed: `cd /Users/chris/workspace/Involute/packages/server && npx prisma db seed`.
+- **Imported team for cross-checks**: The imported team is "SON" when the imported dataset is present. Use the team selector in the web UI header to switch to SON for VAL-CROSS-005 import-to-web validation; if SON is absent after alignment setup, do not treat it as a blocker for rerunning unrelated assertions.
+- **Multi-team selector**: The team selector is in the shared header. INV and APP must be present after alignment setup; SON is only required when rerunning import-to-web assertions.
+- **API error state (VAL-WEB-018)**: Do not stop shared services. Use the runtime override path by navigating with `?involuteApiUrl=http://127.0.0.1:9/graphql` to force a browser-session-only unreachable API and validate the friendly error UI non-destructively.
+- Evidence: capture annotated screenshots for every UI assertion and save supporting GraphQL responses when browser network tooling does not expose enough detail.
+- Known friction: agent-browser may lose refs after drawer transitions/reloads, so re-snapshot frequently; browser network output may list URLs without GraphQL payloads, requiring curl cross-verification.
+- Concurrency: cap Web UI validators at 3 concurrent sessions on this machine because available free memory was ~2.35 GiB during this run and each browser session adds meaningful overhead.
+

.factory/library/web-ui-validation-data-alignment.md

@@ -0,0 +1,14 @@
+# Web UI validation data alignment
+
+- Run `cd /Users/chris/workspace/Involute/packages/server && pnpm setup:web-ui-validation` before web-ui user-testing reruns.
+- The setup is idempotent and backend-owned. It ensures:
+  - `INV` exists with the canonical 6 workflow states.
+  - `APP` exists with the canonical 6 workflow states for team-selector validation.
+  - `VAL` exists as a dedicated empty-board validation team with the canonical 6 workflow states and no seeded issues.
+  - Canonical labels are present/queryable.
+  - `INV` has six uniquely titled validation cards (`web-ui-validation: <State> validation card`) plus 60 backlog cards titled `web-ui-validation: Many issues NN`.
+  - Imported `SON` data remains intact; if `SON` exists, the setup backfills the canonical 6 workflow states so web validators can switch to SON without missing-column drift.
+- Safe rerun behavior:
+  - Existing matching validation issues are reused rather than duplicated.
+  - Existing imported issues/comments are untouched.
+  - The many-issues scenario is topped up to 60 cards if validators consumed or deleted some.

.factory/services.yaml

@@ -5,6 +5,8 @@ commands:
   typecheck: pnpm -r typecheck
   test: pnpm -r test --run
   lint: pnpm -r lint
+  setup_web_ui_validation_data: cd /Users/chris/workspace/Involute/packages/server && pnpm setup:web-ui-validation
+  restore_son_validation_data: cd /Users/chris/workspace/Involute/packages/server && pnpm setup:son-validation
 
 services:
   postgres:
@@ -22,7 +24,7 @@ services:
     depends_on: [postgres]
 
   api:
-    start: "cd /Users/chris/workspace/Involute/packages/server && PORT=4200 node dist/index.js"
+    start: "cd /Users/chris/workspace/Involute/packages/server && pnpm build && PORT=4200 node dist/index.js"
     stop: "lsof -ti :4200 | xargs kill 2>/dev/null || true"
     healthcheck: "curl -sf http://localhost:4200/health"
     port: 4200

.factory/validation/cli/scrutiny/reviews/cli-comment-commands.json

@@ -0,0 +1,28 @@
+{
+  "featureId": "cli-comment-commands",
+  "reviewedAt": "2026-04-03T02:02:23.412578+00:00",
+  "commitId": "b9a286c2827eb67fc04ad313677aaf33e9635b26",
+  "transcriptSkeletonReviewed": true,
+  "diffReviewed": true,
+  "status": "fail",
+  "codeReview": {
+    "summary": "The CLI comment commands and identifier lookup are mostly implemented, but the feature does not fully preserve issue-id support promised by the command contract for non-UUID issue IDs, and the added tests miss that regression.",
+    "issues": [
+      {
+        "file": "packages/cli/src/index.ts",
+        "line": 571,
+        "severity": "blocking",
+        "description": "`comments list`/`comments add` now treat the argument as either a UUID or an identifier and otherwise route through `fetchIssueByIdentifier()`. That means previously supported opaque issue IDs that are not UUID-shaped (for example imported or mocked issue IDs accepted by the GraphQL `issue(id)` field) are now incorrectly looked up as identifiers and fail with 'Issue not found'. The feature requirement and command name both promise `<issueId-or-identifier>`, so this is a behavior regression for valid issue IDs outside the UUID format."
+      }
+    ]
+  },
+  "sharedStateObservations": [
+    {
+      "area": "skills",
+      "observation": "The CLI worker skill's manual verification step assumes workers can start fresh services on ports 4200/4201, but this session had to validate against an already-running API and a Vite fallback port. The worker documented this as a procedure deviation, suggesting the skill does not reflect current mission constraints around occupied but healthy ports.",
+      "evidence": "Handoff skillFeedback.deviations for worker session 22eb4598-c9f0-4d15-9c1f-a2186c1af7b7; AGENTS.md fixes API/Web ports to 4200/4201 while the handoff reports validation on existing 4200 and fallback 4217."
+    }
+  ],
+  "addressesFailureFrom": null,
+  "summary": "Reviewed the feature handoff, transcript skeleton, cli-worker skill, shared-state docs, and commit `b9a286c2827eb67fc04ad313677aaf33e9635b26`. Found one blocking regression: the new identifier-resolution path no longer honors non-UUID issue IDs even though the command contract accepts issue IDs or identifiers."
+}

.factory/validation/cli/scrutiny/reviews/cli-issue-commands.json

@@ -0,0 +1,28 @@
+{
+  "featureId": "cli-issue-commands",
+  "reviewedAt": "2026-04-03T00:00:00Z",
+  "commitId": "a99c06549ca94275d8594a1cf6491d7d28eb6d60",
+  "transcriptSkeletonReviewed": true,
+  "diffReviewed": true,
+  "status": "fail",
+  "codeReview": {
+    "summary": "The CLI command set is broadly implemented, but `issues show <identifier>` is not reliable once a team accumulates more than 100 issues because the lookup queries only the first 100 issues for that team and then filters client-side. This can incorrectly report 'Issue not found' for valid issues, so the feature does not fully satisfy the required show behavior.",
+    "issues": [
+      {
+        "file": "packages/cli/src/index.ts",
+        "line": 435,
+        "severity": "blocking",
+        "description": "`fetchIssueByIdentifier()` resolves an issue by querying `issues(first: 100, filter: { team.key.eq })` and then searching the returned page client-side (`find(...)`). For teams with more than 100 issues, any valid identifier beyond the first page is invisible to `issues show`, `issues update`, and comment commands that depend on this helper, causing false 'Issue not found' errors for existing issues."
+      }
+    ]
+  },
+  "sharedStateObservations": [
+    {
+      "area": "skills",
+      "observation": "The worker's transcript says the feature was 'already implemented and tested' before review, but the committed diff clearly adds substantial new command logic and a new test file. This suggests the skill/handoff guidance does not strongly enforce accurate reporting of what changed during the session.",
+      "evidence": "Handoff summary says 'already implemented and tested', while commit a99c065 adds 864 lines across `packages/cli/src/index.ts` and `packages/cli/src/commands/issues.test.ts`."
+    }
+  ],
+  "addressesFailureFrom": null,
+  "summary": "Reviewed the mission context, handoff, transcript skeleton, skill file, and commit `a99c06549ca94275d8594a1cf6491d7d28eb6d60`. Found one high-confidence blocking bug: issue lookup is capped to the first 100 issues per team and filtered client-side, so valid identifiers can become unreachable in `issues show` and dependent update/comment flows."
+}

.factory/validation/cli/scrutiny/reviews/cli-scaffold-and-config.json

@@ -0,0 +1,28 @@
+{
+  "featureId": "cli-scaffold-and-config",
+  "reviewedAt": "2026-04-03T00:00:00Z",
+  "commitId": "943b59c",
+  "transcriptSkeletonReviewed": true,
+  "diffReviewed": true,
+  "status": "fail",
+  "codeReview": {
+    "summary": "The feature adds the expected config storage, GraphQL client bootstrap, help output, build target, and error normalization, but it does not actually make the documented top-level `--json` flag work for commands like `teams`, so requirement (7) is not fully implemented.",
+    "issues": [
+      {
+        "file": "packages/cli/src/index.ts",
+        "line": 806,
+        "severity": "blocking",
+        "description": "Requirement (7) says all commands support a `--json` flag, but the command tree is defined as `teams -> list` / `states -> list` / `labels -> list` while `--json` is only registered on the subcommands. Commander rejects `involute teams --json` with `unknown option '--json'`, so the advertised global `involute --json` / per-command JSON mode does not work for these commands as implemented. This is user-visible and contradicts both the feature spec and the handoff's manual verification claim that `node packages/cli/dist/index.js teams --json` succeeds."
+      }
+    ]
+  },
+  "sharedStateObservations": [
+    {
+      "area": "skills",
+      "observation": "The `cli-worker` skill's verification checklist tells workers to run `pnpm lint`, but this worker's transcript and handoff only show tests, typecheck, and build. The procedure and what scrutiny expects are out of sync enough that a worker skipped lint while still marking the feature complete.",
+      "evidence": ".factory/skills/cli-worker/SKILL.md step 4 requires `cd packages/cli && pnpm lint`; transcript skeleton for session 6e838de0-a239-448d-9a3c-ec54762e5764 and the handoff verification list contain no lint command."
+    }
+  ],
+  "addressesFailureFrom": null,
+  "summary": "Reviewed feature `cli-scaffold-and-config` via mission metadata, handoff, transcript skeleton, skill instructions, and commit `943b59c`. The implementation mostly matches the scaffold/config requirements, but it fails the `--json` support requirement because `teams --json` is rejected by Commander, so the feature should not pass scrutiny in its current form."
+}

.factory/validation/cli/scrutiny/reviews/cli-verify-test-isolation.json

@@ -0,0 +1,21 @@
+{
+  "featureId": "cli-verify-test-isolation",
+  "reviewedAt": "2026-04-03T02:02:15.028821+00:00",
+  "commitId": "01912d5",
+  "transcriptSkeletonReviewed": true,
+  "diffReviewed": true,
+  "status": "pass",
+  "codeReview": {
+    "summary": "Reviewed commit 01912d5, the worker handoff, transcript skeleton, and the affected CLI test files. The fix directly addresses the stated isolation failure by clearing stale legacy mappings before verify re-imports and by serializing CLI test files that share the same PostgreSQL database. I did not find a high-confidence, actionable bug within the requested scope.",
+    "issues": []
+  },
+  "sharedStateObservations": [
+    {
+      "area": "skills",
+      "observation": "The feature is labeled with skillName `backend-worker`, but the completed worker session used the `cli-worker` procedure and the change lives entirely under `packages/cli`. The shared mission state should reflect the CLI ownership consistently to avoid misrouting future work/reviews.",
+      "evidence": "features.json:1789-1807 lists `cli-verify-test-isolation` with `skillName: \"backend-worker\"`; the handoff file `/Users/chris/.factory/missions/6774ac71-5dc9-4936-9303-c902a364ac7c/handoffs/2026-04-03T01-35-36-511Z__cli-verify-test-isolation__6cf6ae57-6614-49f4-acf3-a1ead2aa568f.json` records a CLI-only fix in `packages/cli/*` and `skillFeedback` discusses the worker skill choice."
+    }
+  ],
+  "addressesFailureFrom": null,
+  "summary": "Pass. The reviewed change is scoped to CLI test isolation, matches the failure description, and the diff shows a credible fix: verify-state reset now removes stale mapping rows that can poison idempotent re-import, while Vitest file parallelism is disabled because the CLI suites share one mutable PostgreSQL database. No blocking or non-blocking code defects were identified in this feature review."
+}

.factory/validation/cli/scrutiny/reviews/fix-cli-command-level-json-flags.json

@@ -0,0 +1,15 @@
+{
+  "featureId": "fix-cli-command-level-json-flags",
+  "reviewedAt": "2026-04-03T05:04:55Z",
+  "commitId": "5482b04",
+  "transcriptSkeletonReviewed": true,
+  "diffReviewed": true,
+  "status": "pass",
+  "codeReview": {
+    "summary": "Reviewed the original failing CLI scaffold commit and the follow-up fix commit against current HEAD. The fix correctly wires `teams`, `states`, and `labels` so top-level `--json` works while preserving the existing `list` subcommands, and the regression coverage in `issues.test.ts` exercises all three top-level JSON paths. I did not find any new high-confidence in-scope bugs in this fix.",
+    "issues": []
+  },
+  "sharedStateObservations": [],
+  "addressesFailureFrom": "cli-scaffold-and-config",
+  "summary": "Pass. Commit `5482b04` resolves the prior blocking scrutiny finding from `cli-scaffold-and-config`: `teams --json`, `states --json`, and `labels --json` are now accepted at the resource-command level on current HEAD, with matching regression tests and no new in-scope defects found."
+}

.factory/validation/cli/scrutiny/reviews/fix-cli-comment-nonuuid-issue-id-resolution.json

@@ -0,0 +1,21 @@
+{
+  "featureId": "fix-cli-comment-nonuuid-issue-id-resolution",
+  "reviewedAt": "2026-04-03T05:05:10.700671+00:00",
+  "commitId": "2ddcb75f7c62ddde2e01b4a82ea5a30e18f50e81",
+  "transcriptSkeletonReviewed": true,
+  "diffReviewed": true,
+  "status": "pass",
+  "codeReview": {
+    "summary": "The fix restores the promised `<issueId-or-identifier>` behavior for comment commands by always trying `issue(id)` first and only falling back to identifier lookup when the direct lookup misses. I did not find any new high-confidence bugs in scope from the original failure or the follow-up change.",
+    "issues": []
+  },
+  "sharedStateObservations": [
+    {
+      "area": "skills",
+      "observation": "The cli-worker skill still mandates manual verification against a separately started API server for every CLI change, but this fix feature was fully and appropriately verified through the existing in-process CLI integration harness; the worker explicitly skipped extra manual runs for that reason.",
+      "evidence": "`.factory/skills/cli-worker/SKILL.md` step 4 requires manual server startup and CLI runs, while the fix handoff for worker session `7583a2b1-2efa-4f68-bbbf-8856ecbaf15d` notes the automated comment-command tests already boot a real test server and thoroughly cover the changed resolution path."
+    }
+  ],
+  "addressesFailureFrom": "cli-comment-commands",
+  "summary": "Reviewed the prior failing feature `cli-comment-commands`, the fix feature handoff/transcript, and both commits `b9a286c2827eb67fc04ad313677aaf33e9635b26` and `2ddcb75f7c62ddde2e01b4a82ea5a30e18f50e81`. The fix adequately addresses the original regression by restoring opaque non-UUID issue-id support while preserving identifier fallback behavior, and I found no new actionable issues in scope."
+}