conductor/BASELINE.md

# Validation Baseline

## Date

2026-07-18

## Environment

- Target toolchain: Node.js 20 and npm 10
- Executed toolchain: Node.js 20.20.2 and npm 10.9.8, supplied ephemerally through `npx`
- Docker CLI: available on Windows
- Docker engine: unavailable because Docker Desktop's Linux engine was not running
- Docker inside WSL: unavailable because WSL integration was disabled

## Dependency Installation

- Root `npm ci`: passed under the preinstalled WSL Node 18/npm 9 toolchain; reported 2 high-severity audit findings in `ajv-cli` dependencies.
- Frontend clean install initially failed because `frontend/package-lock.json` was missing `yaml@2.9.0`.
- `npm install --package-lock-only` under Node 20/npm 10 repaired the frontend lockfile.
- Frontend clean install then passed under Node 20/npm 10; npm reported 28 dependency vulnerabilities: 9 low, 6 moderate, and 13 high.
- Backend clean install passed under Node 20/npm 10; npm reported 0 vulnerabilities.

## Automated Checks

### Frontend tests

Command:

```bash
npx --yes --package=node@20 --package=npm@10 npm test -- --watchAll=false --runInBand
```

Result: Passed.

- Test suites: 7 passed, 7 total
- Tests: 433 passed, 433 total
- Snapshots: 0

### Frontend production build

Command:

```bash
npx --yes --package=node@20 --package=npm@10 npm run build
```

Result: Passed.

### Backend TypeScript build

Command:

```bash
npx --yes --package=node@20 --package=npm@10 npm run build
```

Result: Passed.

## Schema Matrix

Twelve `valid-*.json` project definitions pass validation against `shared/schemas/conductor-project.schema.json`, including the Slice 1 all-components fixture.

Two schema-invalid fixtures failed validation as expected:

- `invalid-dropdown-option-shape.json`
- `invalid-missing-required.json`

Two diagnostic-invalid fixtures passed structural schema validation as designed because their defects require semantic/runtime diagnostics:

- `invalid-template-malformed.json`
- `invalid-template-missing-component.json`
## Slice 1 Manual Acceptance

User validation completed successfully on 2026-07-18:

- All five new components can be configured and manipulated in the Visual Editor.
- Preview interaction, disabled and hidden behavior, and Status Panel tones work as expected.
- Visual Editor and JSON Editor synchronization works.
- Save/load persistence and existing-component regression checks pass.


## Slice 2 Increment 1 Validation

Validation completed on 2026-07-18 for visual anonymous REST action authoring.

### Focused editor tests

Command:

```bash
npm test -- --watchAll=false --runInBand --runTestsByPath \
  src/components/ActionInspector/actionEditorUtils.test.ts \
  src/components/ActionInspector/ActionInspector.test.tsx
```

Result: Passed.

- Test suites: 2 passed, 2 total
- Tests: 23 passed, 23 total
- Covers canonical CRUD, duplicate-ID safety, reference discovery, request-map and URL validation, anonymous duplication, immediate document synchronization, and invalid local drafts.

### Full target-toolchain checks

Commands:

```bash
npx --yes --package=node@20 --package=npm@10 npm test -- --watchAll=false --runInBand
npx --yes --package=node@20 --package=npm@10 npm run build
```

The frontend commands ran from `frontend/`. The build command also ran from `backend/`.

Results:

- Frontend tests: 9 suites and 456 tests passed; 0 snapshots.
- Frontend production build: passed.
- Backend TypeScript build: passed.

### Schema fixture matrix

Each fixture was checked with:

```bash
./node_modules/.bin/ajv validate \
  -s shared/schemas/conductor-project.schema.json \
  -d <fixture> \
  --spec=draft2020
```

Results:

- 13 of 13 `valid-*.json` fixtures passed, including `valid-visual-rest-actions.json`.
- 2 of 2 schema-invalid fixtures failed as expected.
- 2 of 2 diagnostic-invalid fixtures passed structural validation as designed.

### Standalone frontend TypeScript check

Command:

```bash
npx tsc --noEmit
```

Result: Blocked by an existing dependency/toolchain mismatch. Frontend TypeScript 4.9 cannot parse syntax in resolved `@types/node@26.1.0` (first error: `node_modules/@types/node/ffi.d.ts(94,21): TS1139`). The CRA production build performs the application TypeScript compile and passed.

### Visual QA

The frontend development server compiled successfully at `http://localhost:3000`. In-app browser automation could not start during implementation while Docker Desktop was not running; its Node REPL kernel reported `helper_unknown_error: setup refresh had errors` during Windows sandbox setup.

After Docker Desktop and the app were started, the user completed the Slice 2 Increment 1 manual acceptance on 2026-07-19. The accepted workflow covered visual anonymous REST action authoring, a Button `events` entry inserted through canonical JSON for an `onClick` action reference, and referenced-action deletion confirmation. Full Slice 2 workflow-launcher and dependent-data acceptance remains pending later increments.


## Runtime Startup

Initial backend startup against a clean SQLite database failed with:

```text
SqliteError: no such table: projects
```

Cause: `backend/src/index.ts` statically imported `app` before calling `initDatabase()`. Importing the app loaded project routes and prepared SQL statements before the `projects` table existed.

Fix: run `initDatabase()` first, then dynamically import the Express app and start listening.

After the fix, clean-database startup, HTTP health, complete CRUD, cleanup, and persistence across a backend container restart all passed.

## Docker Validation

Docker Desktop was started and validation completed. Both images built, both services started, the frontend compiled, the backend initialized SQLite, and health, CRUD, cleanup, and restart-persistence checks passed.

## Baseline Status

Passing for the current automated and Docker smoke-test scope:

- [x] Locked frontend dependencies repaired
- [x] Frontend tests pass
- [x] Frontend production build passes
- [x] Backend TypeScript build passes
- [x] Schema matrix behaves as expected
- [x] Backend starts against a clean database
- [x] Health and CRUD smoke checks pass
- [x] Persistence survives a backend container restart
- [x] Docker Compose build and integration checks pass

Remaining release work includes broader backend tests, browser end-to-end tests, security regression tests, and resolution of the frontend dependency audit findings.

## Slice 2 Increment 2 Button Event Validation

On 2026-07-19, focused tests passed (3 suites / 6 tests), full frontend tests passed (12 suites / 462 tests), the frontend and backend builds passed, and the schema matrix passed at 13 / 2 / 2. `ComponentEvent.inputMap` was documented as compatibility-only; executed request inputs continue to use component/variable REST templates. Automated Preview dispatch passed. The user then manually verified creating a REST action and assigning it visually to a Button; Increment 2 Button `onClick` acceptance passed.

## Slice 2 Request Input Validation

On 2026-07-19, focused request-input tests passed at 3 suites / 9 tests, the full frontend suite passed at 14 suites / 467 tests, frontend and backend builds passed, and the schema matrix passed at 13 / 2 / 2.

The UI writes executed component/variable templates to URL, header, query, and body fields while excluding path parameters and `inputMap`. Standalone `tsc` reproduced the recorded dependency mismatch. Manual request-input acceptance remains pending.

### Pending manual request-input acceptance

1. Start Docker Desktop and run Conductor through Docker Compose.
2. Open a project containing a Text Input or Dropdown, a Button, and an anonymous REST action.
3. Edit the action and add a query parameter such as `item`.
4. In Request value reference, choose the component, choose `Query: item`, and insert the reference.
5. Confirm canonical JSON immediately contains `"item": "{{components.<componentName>.value}}"` and does not add `inputMap`.
6. Assign the action to the Button, enter or select a Preview value, and execute it.
7. Confirm the outgoing request uses the runtime component value and loading, response, and error state remain ephemeral.
8. Confirm path parameters are not offered as destinations and raw URL/header/query/body template editing still works.
9. If an existing JSON-authored variable is available, repeat insertion and verify `{{variables.<name>}}` resolution.

## Slice 2 Response Binding and Variable Validation

On 2026-07-20, focused configuration tests passed under Node 20/npm 10 at 2 suites / 14 tests. The full frontend suite passed at 15 suites / 477 tests with 0 snapshots. The frontend CRA production compile and backend TypeScript build passed. The schema fixture matrix passed at 13 valid fixtures, 2 expected schema failures, and 2 diagnostic-invalid fixtures that remain structurally valid.

Automated coverage verifies canonical response-binding and variable creation/editing/deletion, the `onSuccess` default for new action-response bindings, supported and unambiguous target filtering, typed variable default parsing, canonical synchronization, binding-editor deletion lifecycle, and reference-aware variable deletion warnings. Existing legacy `onClick` compatibility remains in runtime and diagnostics and supports one-way visual migration; the UI cannot create a new `onClick` response binding. No deprecated `action.responseMapping` behavior was added.

Standalone frontend `npx tsc --noEmit` continues to fail in `node_modules/@types/node/ffi.d.ts` because the project's TypeScript 4.9 compiler cannot parse the resolved `@types/node@26.1.0` declarations. This is reported separately from the successful CRA production TypeScript compile.

Manual acceptance is pending. During the 2026-07-20 audit, the Docker CLI reported that it is unavailable in this WSL distro and Docker Desktop WSL integration must be enabled. Compose/service/health validation and the request-input browser checklist therefore could not be completed here. The earlier request-input workflow and the new response-binding/variable workflow have not been marked manually accepted.

### Partial manual request-input checkpoint

On 2026-07-20, the user confirmed that the `item` query-parameter row and guided Request value reference insertion into `Query: item` looked correct. This is a partial checkpoint, not full manual acceptance. Preview execution, outgoing-request inspection, ephemeral-state verification, path-destination exclusion, raw-template regression coverage, and variable reference resolution remain pending.