conductor/SLICE2.md

8.8 KiB

Slice 2: Visual Configuration

Status

In progress — response bindings and variable authoring complete; manual acceptance and page-load actions next

Objective

Allow an MVP project to be configured through the GUI without routine hand-editing of canonical JSON.

Dependencies

  • Slice 1 component contracts
  • Existing action, event, binding, variable, and Preview models
  • Canonical top-level project.bindings decision

In Scope

  • Visual REST Action CRUD
  • Component events, request input mappings, response bindings, variables, and page-load configuration
  • Immediate synchronization with canonical project JSON

Out of Scope

  • AI-generated configuration
  • Chained actions, general orchestration, and advanced JSONPath authoring

Tasks

  • Design a consistent, progressively disclosed workflow for editing actions, events, bindings, variables, and page-load behavior.
  • Implement REST Action list, create, edit, duplicate, and reference-aware delete operations.
  • Add method, URL, headers, query, path, and body controls for anonymous REST actions.
  • Decide and implement the canonical timeout field before exposing a timeout control; the current schema and runtime use a fixed backend timeout.
  • Keep Slice 2 authentication authoring anonymous-only and defer credential-backed authentication controls to Slice 3.
  • Implement component event configuration for Button onClick, including add/change/clear and dangling-reference diagnostics.
  • Implement request input authoring through executed REST request templates; do not write inert ComponentEvent.inputMap.
  • Implement response source and component/variable target selection.
  • Default new action-response bindings to onSuccess without offering legacy onClick for new records.
  • Implement page-load action configuration for initial data population.
  • Add variable declaration and typed default-value editing.
  • Warn before deleting referenced actions, variables, or components. Action and variable deletion are covered; component deletion remains.
  • Ensure every REST action visual edit immediately updates canonical JSON while invalid drafts remain local.
  • Add slice-wide tests, examples, and documentation updates. Coverage and the representative fixture are complete through response bindings and variables; page-load and final slice acceptance remain.

Implementation Order

  1. REST action authoring: Add canonical action CRUD, method/URL/request controls, local validation, diagnostics, reference-aware deletion warnings, focused tests, and a representative example project.
  2. Component events and request inputs: Configure Button onClick first, then supported onChange events and component/variable request templates.
  3. Response bindings and variables: Author top-level project.bindings with onSuccess defaults, supported response paths and targets, plus variable declarations/defaults.
  4. Page-load actions: Add the minimum page lifecycle contract needed to execute configured onLoad actions without introducing general orchestration.
  5. Slice acceptance and hardening: Complete dangling-reference diagnostics, persistence/JSON synchronization coverage, representative examples, builds, schema validation, and manual workflows.

Each increment writes only canonical configuration into the shared project document. Preview execution values, loading flags, responses, errors, and variable values remain ephemeral runtime state.

Acceptance Criteria

  • A user can build the workflow launcher without editing JSON.
  • Actions, inputs, triggers, and response mappings can be configured visually.
  • Initial dropdown/table population can be configured visually.
  • Dangling references are reported before Preview execution.
  • Visual and JSON editors remain synchronized and save/load preserves configuration.

Validation

  • Standalone frontend TypeScript check passes. TypeScript 4.9 currently cannot parse the resolved @types/node@26.1.0; the CRA production compile passes.
  • Frontend production build passes through the response-binding and variable increment.
  • Editor interaction and Preview dispatch tests pass through the response-binding and variable increment.
  • The representative canonical JSON validates through the response-binding and variable increment.
  • Increment 1 manual REST action authoring and referenced-action deletion workflow passes.
  • Manual workflow-launcher and dependent-data scenarios pass.

Risks and Open Questions

  • Configuration UI needs progressive disclosure to remain manageable.
  • Page-load support must not become a general workflow engine.
  • Authentication controls must reference secrets without storing credential values.

Progress Log

  • 2026-07-18: Restored project state from CODEX.md, TASKS.md, MVP_SCOPE.md, and this plan.
  • Verified the clean main branch against a freshly fetched origin/main; both point to b9697cc8b11bce806887d6e7a29098a308b0846a.
  • Re-ran the pre-change frontend baseline successfully: 7 suites and 433 tests passed.
  • Audited the canonical action/event/binding model, Visual Editor, read-only Actions & Bindings Inspector, Preview execution path, schema validation, examples, and existing tests.
  • Chose visual REST action authoring as the first coherent vertical increment.
  • Completed canonical anonymous REST action creation, editing, duplication, and reference-aware deletion in Actions & Bindings.
  • Added progressive request controls for method, endpoint URL, headers, query parameters, static path parameters, and request body; invalid drafts remain local and runtime state remains separate.
  • Added action-definition, duplicate-ID, header-name, and path-template diagnostics plus referenced-deletion warnings.
  • Added 23 focused tests plus valid-visual-rest-actions.json.
  • Validation passed under Node 20/npm 10: 9 frontend suites / 456 tests, frontend production build, backend TypeScript build, and the 13-valid / 2-schema-invalid / 2-diagnostic-invalid schema matrix.
  • Standalone tsc --noEmit remains blocked by the existing TypeScript 4.9 / @types/node@26.1.0 dependency mismatch; the application production build compiles successfully.
  • In-app browser automation could not start during implementation while Docker Desktop was not running. After Docker Desktop and the app were started, the user manually accepted Increment 1 on 2026-07-19, including a Button onClick event inserted through canonical JSON and the referenced-action deletion workflow.

Handoff

  • Last completed: Visual response-binding and variable authoring, with automated validation.
  • Next action: Complete manual request-input and response-binding/variable acceptance, then implement visual page-load action authoring.
  • Known blockers: Docker Desktop integration is unavailable in the current WSL distro, so manual acceptance remains pending. Standalone frontend tsc retains its recorded tooling limitation.
  • Current pushed baseline: 6fd084c Add visual REST request input authoring.
  • Continuation and manual-test instructions: NEXT_SESSION_PROMPT.md.

Response Binding and Variable Increment

Implemented and audited through 2026-07-20 in the working tree:

  • Visual canonical project.bindings create, edit, and delete controls.
  • Existing REST action response selection with supported component and declared-variable targets.
  • New bindings default to onSuccess and cannot select legacy onClick; existing legacy onClick bindings are preserved and can migrate one-way to onSuccess.
  • New target choices exclude unsupported component properties and ambiguous duplicate component names.
  • Visual variable declaration, rename, type, default value, description, and deletion controls with reference-aware warnings.
  • No action.responseMapping, ComponentEvent.inputMap, authentication, secrets, page-load execution, or runtime-state persistence was added.
  • Automated validation passes: 2 focused suites / 14 tests, 15 full frontend suites / 477 tests under Node 20/npm 10, frontend CRA production compile, backend build, and the 13 / 2 / 2 schema matrix.
  • Standalone TypeScript remains blocked by the documented TypeScript 4.9 / @types/node@26.1.0 parser incompatibility.

Manual acceptance is separate from automated coverage. The preceding request-input workflow is still pending user confirmation because Docker Desktop integration is unavailable in this WSL distro. The response-binding and variable workflow is also pending proportional manual acceptance. Neither is marked accepted.

On 2026-07-20, the user confirmed the partial request-input checkpoint for adding the item query parameter and inserting the selected component through Request value reference into Query: item. The remaining Preview, request inspection, runtime-state, destination-exclusion, raw-template, and variable-resolution checks are still pending; full manual acceptance is not recorded.

Next increment: page-load action authoring.