conductor/TESTING.md

Conductor Manual Testing

This document is the durable manual-testing checklist for Conductor. Automated test results belong in BASELINE.md; this file covers behavior that needs a person to verify in the running application.

Do not mark a workflow accepted from automated coverage alone. Record the date, tester, environment, and any observations in the result block for that workflow.

Status Summary

Workflow	Status
Slice 1 components and editor synchronization	Accepted 2026-07-18
Anonymous REST action authoring and referenced deletion	Accepted 2026-07-19
Visual Button onClick assignment	Accepted 2026-07-19
Guided request-input query insertion	Accepted 2026-07-20
Complete request-input execution	Accepted 2026-07-28
Response bindings and variable authoring	Accepted 2026-07-29
Page-load actions	Accepted 2026-07-29
Final Slice 2 workflow-launcher and dependent-data acceptance	Accepted 2026-07-30
Page-load Actions & Bindings diagnostics	Accepted 2026-07-30
Runtime-expanded Preview background	Accepted 2026-07-30
MVP component properties and basic appearance	Accepted 2026-07-31
Actions & Bindings information architecture	Accepted 2026-07-31
Final Slice 2 sign-off	Accepted 2026-07-31
Slice 2a request-reference usability	Complete and signed off
Slice 3 authentication and secrets	Complete and signed off 2026-08-02
Slice 4 proxy security and execution history	Complete and signed off 2026-08-03
Slice 5 validation and error handling	Complete and signed off 2026-08-04

Slice 5 Manual Gate

Slice 5 implementation and automated validation completed on 2026-08-04. The proportional manual gate is defined in SLICE5.md and covers rejected JSON/semantic defects, atomic save/load rollback, Preview failure and recovery states, unsaved-edit preservation, explicit-null and empty-container round trips, discard confirmations, and cross-view diagnostic agreement. Do not mark Slice 5 complete until those workflows pass and the user grants explicit final sign-off.

The first manual run passed malformed-JSON Test 1A. Tests 1B–1D exposed a frontend crash caused by the invalid validation response omitting its warnings array. The backend contract and defensive frontend parser were corrected; backend automation, 23 frontend suites / 513 tests, production build, Docker rebuild, and direct checks of all three failed response shapes pass. Manual retest of 1B–1D is pending; Test 2 has not started.

Tests 1B–1D subsequently passed. Test 3B received HTTP 402 from the external httpbingo endpoint, which is recorded as an unavailable test dependency rather than a Conductor result. The manual procedure now uses a Compose-only local mock and exact server-controlled internal-origin exception. Controlled HTTP 200, one-second delay, and HTTP 503 responses all passed through the proxy; manual Test 3B retest remains pending.

The controlled-fixture continuation passed Tests 1–5. Test 6A found that JSON Editor omitted the shared validation summary, while 6B was not run because the partial JSON-edit instruction was too vague. JSON Editor now includes the shared summary with regression coverage; 24 frontend suites / 515 tests and production build pass, and Docker was rebuilt. A complete SLICE5_TEST6B_PROJECT.json replaces the partial-edit instruction and produces exactly the intended transform compatibility warning. Retest 6A, Test 6B, and cleanup remain pending.

Retest 6A and prepared-document Test 6B passed, and the user confirmed all tests pass. Cleanup cleared all disposable execution history, deleted project #14, removed the mock fixture/internal exception, restored standard Compose, and confirmed healthy backend/frontend plus empty executions, secrets, secret-key configuration, and internal-origin configuration. Manual acceptance is complete; explicit final Slice 5 sign-off remains pending.

Slice 6 Automated Release Gate — 2026-08-05

Automation and the authoritative manual procedure in SLICE6_MANUAL_TEST.md are complete.

Passing evidence:

• Backend: 27 tests, including isolated HTTP API, all authentication modes, project atomicity/round trips, process restart, and SQLite backup/restore.
• Frontend: 25 suites / 517 tests; standalone tsc --noEmit; production build.
• Schema: 14 valid, 2 expected-invalid, and 2 diagnostic-invalid fixtures.
• Browser E2E: 1 deterministic Docker/Chromium workflow covering dependent data, launcher execution, dashboard refresh/selection/details, save, reload, and rerun readiness.
• Docker: rebuilt controlled-mock stack, restart persistence, backend health, frontend HTTP 200, then standard-stack restoration and cleanup.
• Security: proxy/auth/redaction regression suites pass, tracked-source credential-pattern scan returned no matches, backend production dependency audit reports zero vulnerabilities.

One release-boundary defect was fixed before this gate: selecting a Table row now applies a validated runtime-only components.<table>.selectedRow → display-value binding. The deterministic demo and E2E test exercise it.

Known release risk: the legacy Create React App dependency tree retains high advisories in build/development tooling with no supported non-breaking npm audit fix. This requires a packaging/toolchain decision in Slice 8; it is not recorded as a passing audit.

Automation and human acceptance remain distinct. SLICE6_MANUAL_TEST.md, cleanup, and explicit final sign-off passed; Slice 6 is complete.

Slice 6 manual progress

• On 2026-08-06, the user reported Tests 1–4 pass.
• Test 5 setup was prepared on 2026-08-07: the controlled mock override, a temporary backend encryption key, four disposable secret records, and project Slice 6 Auth Manual (#21) with five valid authentication actions plus one expected missing-secret failure.
• Direct preflight returned HTTP 200 for Anonymous, Basic, Bearer, API-key header, and API-key query. Disposable marker searches passed against history and backend logs; preflight history was then cleared so only manual executions remain.
• On 2026-08-07, the user reported all remaining manual tests pass successfully. This completes Tests 1–6.
• Stored execution history showed redacted credentials, sanitized query URLs, and the expected SECRET_NOT_FOUND failure. Exact searches found none of the five disposable marker values in stored history or backend logs.
• Cleanup deleted projects #20 and #21, all four disposable secrets, and execution history; stopped the override stack; and restored standard Compose.
• Final verification passed: backend health ok, frontend HTTP 200, empty executions/secrets, empty CONDUCTOR_SECRET_KEY and CONDUCTOR_PROXY_INTERNAL_ORIGINS, and no mock service.
• The user granted explicit final Slice 6 sign-off on 2026-08-07 with the exact wording: “I grant explicit final Slice 6 sign-off.” Slice 6 is complete.

The user granted explicit final Slice 5 sign-off on 2026-08-04 with the wording: “Confirm slice5 signoff.” Slice 5 is complete.

Slice 4 Manual Gate

The five workflows in SLICE4.md passed on 2026-08-02 after focused remediation and repetition. Initial testing passed approved destinations, controls/recovery, and execution history; mixed-answer/rebinding DNS checks were initially unavailable, and private destination URLs in backend failure logs failed redaction. The logger was reduced to safe structured metadata. A disposable authoritative DNS fixture then proved mixed public/loopback answers fail closed and rebinding cannot bypass pinned validated addresses. The focused logging retest found zero private literals or raw transport errors. IPv6 literal classification was also corrected and retested. All disposable secrets, history, fixtures, networks, keys, and exceptions were removed. This is manual evidence separate from automation.

An independent manual re-test result was supplied on 2026-08-02 using rebuilt Docker Compose and isolated Playwright Chromium. Every previously failed or unavailable check passed: approved-destination and credential regressions, mixed-answer DNS, rebinding/address pinning, loopback IPv4/IPv6 classification, all credential modes across success/failure/redirect paths, exact marker searches, safe backend logging, and cleanup. The reported backend regression result was 18/18 passing. No source was edited and nothing was committed or pushed during that re-test. No remaining manual limitation was identified. The tester explicitly stated that this result is not final Slice 4 sign-off.

The user granted final Slice 4 sign-off on 2026-08-03 with the exact wording: “I grant explicit final Slice 4 sign-off.” Final consolidated validation then passed: backend build and 7 compiled test files, 22 frontend suites / 509 tests, frontend production build, the 13 / 2 / 2 schema matrix, rebuilt Docker Compose services, backend health, frontend HTTP 200, and empty secrets/history/configuration cleanup checks. Slice 4 is complete; no further Slice 4 manual testing is required.

Test Environment Setup

1. Start Docker Desktop

1. Start Docker Desktop on the host computer.

2. If using WSL, open Docker Desktop settings.

3. Select Resources, then WSL Integration.

4. Enable integration for the WSL distribution containing this repository.

5. Apply the changes and restart Docker Desktop if prompted.

6. From the repository root, verify that Docker is available:

   docker info
   

Expected result: the command displays client and server information without a connection or WSL-integration error.

2. Start Conductor

From the repository root, run:

docker compose up --build

Leave this terminal running. In another terminal, run:

docker compose ps
curl http://localhost:4000/api/health

Expected results:

• The frontend and backend services are running.
• The health request returns JSON containing "status":"ok".
• http://localhost:3000 opens the Conductor application.

If startup fails, capture docker compose ps and:

docker compose logs backend frontend

Do not continue until both services and the health endpoint work.

Canonical JSON and Runtime State

Several workflows ask you to inspect canonical JSON:

1. Select JSON Editor in the application navigation.
2. Locate the relevant section under project, such as actions, bindings, or variables.
3. Do not add runtime-only fields merely to test them.

Runtime values are expected to exist only while Preview is running. Canonical JSON must not gain fields containing:

• current input or selection values;
• loading flags;
• action responses;
• action or component errors;
• updated runtime variable values.

Configured component defaults and declared variable defaults are canonical and are expected to remain in JSON.

Test 1: Request-Input Authoring and Execution

Purpose: verify that a current component or variable value can be inserted into an executed REST request template without using compatibility-only inputMap.

Partial status: adding the item query row and guided component insertion was confirmed on 2026-07-20. The remaining steps still need acceptance.

A. Create the test project

1. Open http://localhost:3000.

2. Create a new project, or open a disposable test project.

3. In Visual Editor, add a Text Input.

4. Select the Text Input and give it a unique component name such as itemInput.

5. Add a Button and name it lookupButton.

6. Optionally add a JSON Viewer named requestResult; it will be useful in the response-binding test.

7. Open Actions & Bindings.

8. Select Add REST action.

9. Configure:

   • Name: Look up item
   • Method: GET
   • URL: https://httpbin.org/anything
   • Authentication: confirm it remains Anonymous

10. Finish the action edit, then return to Visual Editor.

11. Select lookupButton and assign Look up item as its onClick action.

Expected result: JSON contains a Button event referencing the action ID, but no inputMap is created.

B. Add the guided query reference

1. Return to Actions & Bindings.
2. Edit Look up item.
3. Find Query parameters and select Add row.
4. Enter item in the key field. The value may initially remain blank.
5. Find Request value reference in the same action editor.
6. Select itemInput (TextInput) as the source.
7. Select Query: item as the destination.
8. Select Insert reference.
9. Return to the Query parameters section.

Expected result: the value of item is:

{{components.itemInput.value}}

10. Open JSON Editor and find the action's queryParameters.

Expected canonical fragment:

"queryParameters": {
  "item": "{{components.itemInput.value}}"
}

11. Search the document for inputMap.

Expected result: no ComponentEvent.inputMap was added.

12. Return to the action editor and inspect the Request value reference destination choices.

Expected result: URL, header, query, and body destinations may be offered. Path parameters are not offered.

C. Execute the component reference

1. Open Preview.

2. Enter a recognizable value in the Text Input, for example:

   manual-test-742
   

3. Select the Button once.

4. Wait for the request to complete.

5. Inspect the response or the browser Network panel. For the httpbin endpoint, the response body should echo the request URL or query arguments.

Expected result: the outgoing URL contains an encoded query parameter equivalent to:

?item=manual-test-742

6. While still in the same project, open JSON Editor again.

Expected results:

• The template remains {{components.itemInput.value}}; it was not replaced by manual-test-742.
• No loading, response, error, or current component value was added to JSON.

D. Verify raw template editing still works

1. Edit Look up item again.
2. Add a raw URL suffix, header value, or second query parameter containing literal text or a supported template.
3. Add a body template temporarily if desired. A GET body need not be executed; this step checks that the raw editor remains usable.
4. Confirm the raw value synchronizes to JSON.
5. Confirm the previously inserted item query reference is unchanged.

Expected result: guided insertion does not disable or overwrite subsequent raw URL, header, query, or body editing.

E. Verify a variable request reference

1. In Actions & Bindings, create a variable:

   • Name: testRegion
   • Type: string
   • Default value: east

2. Edit Look up item.

3. Add a query parameter named region.

4. In Request value reference, choose variable testRegion.

5. Choose Query: region, then select Insert reference.

6. Confirm JSON contains:

   {{variables.testRegion}}
   

7. Execute the Button in Preview.

Expected result: the outgoing query includes region=east, while canonical JSON retains the variable declaration and default rather than a runtime copy.

Request-input result

• Docker services and health endpoint passed.
• Guided item query-reference insertion looked correct (2026-07-20).
• Canonical component template and absence of inputMap confirmed.
• Path parameters confirmed absent from guided destinations.
• Runtime component value appeared in the outgoing request.
• Runtime state remained absent from canonical JSON.
• Raw template editing regression passed.
• Variable reference resolved in an executed request.

Tester/date: User, 2026-07-28

Notes or defects: All request-input checks passed. The tester initially looked below the query-parameter editor for Request value reference; the control is at the top of the expanded Request parameters section. No product defect found.

Test 2: Response Bindings and Variables

Purpose: verify visual CRUD for canonical project.bindings and project.variables, response delivery in Preview, legacy compatibility, and runtime-state separation.

A. Test typed variable declarations

1. Open the test project in Actions & Bindings.

2. In Variables, select Add variable.

3. Create statusText:

   • Type: string
   • Default: Not run
   • Description: Latest manual test status

4. Create retryCount with type number and default 2.

5. Create enabled with type boolean and default true.

6. Create metadata with type object and default:

   {"source":"manual"}
   

7. Create items with type array and default:

   []
   

8. Inspect JSON Editor.

Expected result: project.variables contains typed declarations. Number and boolean defaults are JSON numbers and booleans, not quoted strings; object and array defaults have the correct JSON shapes.

9. Edit metadata, replace its default with malformed JSON, and try to save.

Expected result: an actionable validation message appears and the invalid draft does not replace the canonical variable value.

10. Correct the JSON and save it.

Expected result: the corrected default updates canonical JSON.

B. Create and execute a component response binding

1. Ensure the project contains Look up item and a JSON Viewer named requestResult.
2. Ensure lookupButton runs Look up item on click.
3. In Actions & Bindings, select Add response binding.
4. Select Look up item as the REST action response source.
5. Set Response path to body to map the upstream body, or leave it blank to map the complete normalized response envelope.
6. Select requestResult (JsonViewer.value) as the target.
7. Inspect JSON Editor.

Expected results:

• The new record is in top-level project.bindings.
• Its source begins actions.<actionId>.response.
• Its target is components.requestResult.value.
• Its trigger is exactly onSuccess.
• No action.responseMapping was added.

8. Open Preview, enter a value in itemInput, and select the Button.

Expected result: after a successful request, the JSON Viewer displays the mapped response value.

C. Create and execute a variable response binding

1. Return to Actions & Bindings.
2. Add another response binding.
3. Select Look up item as the source action.
4. Use a response path appropriate to the httpbin response, such as body.url.
5. Select statusText (variable) as the target.
6. Confirm the new binding uses onSuccess.
7. Execute the Button successfully in Preview.
8. Execute any request that consumes {{variables.statusText}}, or otherwise observe its downstream behavior.

Expected results:

• The runtime variable receives the mapped response value.
• project.variables.statusText.defaultValue remains Not run in canonical JSON.
• No runtime variable value is saved into canonical JSON.

D. Edit and delete bindings

1. Edit the component response binding.
2. Change its response path, save/finish the edit, and confirm JSON updates.
3. Change its supported target and confirm JSON updates.
4. Delete that binding and accept the confirmation.

Expected results:

• Edits update only the selected top-level binding.
• Deletion removes only that binding.
• Add response binding remains enabled afterward.

E. Verify target restrictions

1. Add or select an unsupported input component such as Text Input.
2. Start adding or editing a response binding and inspect Target choices.

Expected result: unsupported targets such as TextInput.value are not offered.

3. If two components have the same name, inspect the Target choices again.

Expected result: the ambiguous duplicate component name is not offered as a new target, and existing ambiguous bindings receive a diagnostic.

F. Verify variable reference warnings

1. Ensure statusText is referenced by a response binding or request template.
2. Select Delete for statusText.

Expected result: the confirmation identifies the binding or action references that would become unresolved.

3. Cancel and confirm the variable remains.
4. Repeat deletion and accept it only in a disposable project.

Expected result: diagnostics identify the now-unresolved references; unrelated variables and bindings remain unchanged.

G. Verify legacy onClick compatibility

This test needs a pre-existing legacy action-response binding authored through JSON. Do not use the visual editor to create a new legacy binding.

1. In a disposable project, use JSON Editor to add an action-response binding with "trigger": "onClick" and apply the valid JSON.
2. Open Actions & Bindings and inspect the binding.

Expected result: it is displayed with an informational legacy diagnostic and can still execute for a supported component target.

3. Edit the legacy binding.

Expected result: onClick is shown only because this record is already legacy.

4. Change the trigger to On success.

Expected results:

• Canonical JSON changes to "trigger": "onSuccess".
• The editor no longer offers onClick for that migrated record.
• A newly added response binding never offers onClick.

H. Verify failure and ephemeral state

1. Temporarily change the action URL to a URL that will fail or return an error.
2. Execute the Button in Preview.

Expected results:

• The UI exposes a usable loading state followed by an error state.
• onSuccess response bindings do not apply a failed response.
• Loading flags, errors, and responses do not appear in canonical JSON.

3. Restore the valid action URL.

I. Verify save and reload

1. Save the project.
2. Reload it from the project picker.
3. Reopen Actions & Bindings.
4. Confirm actions, Button events, request templates, response bindings, and variable declarations/defaults are preserved.
5. Open Preview and execute the successful workflow again.

Expected result: configured behavior survives persistence, while previous runtime responses, errors, loading state, input values, and modified runtime variables do not.

Response-binding and variable result

• Typed variable declarations/defaults passed.
• Invalid variable draft remained outside canonical JSON.
• Component response binding executed with onSuccess.
• Variable response binding executed without changing its canonical default.
• Binding edit and delete passed.
• Unsupported and ambiguous targets were excluded.
• Referenced-variable deletion warning passed.
• Legacy onClick compatibility and one-way migration passed.
• Failure and ephemeral-state checks passed.
• Save/reload persistence passed.

Tester/date: User, 2026-07-29

Notes or defects: Typed declarations, invalid-draft isolation, component onSuccess mapping, and variable onSuccess mapping passed. The two-request variable check proved runtime statusText changed while its canonical Not run default remained intact. Boolean true authoring initially failed and was fixed with an explicit selector. The original httpbin.org endpoint intermittently returned 503; onSuccess correctly withheld those failures. The verified httpbingo.org endpoint produced successful binding results. Binding edit and selected deletion also passed, with the other binding preserved and Add response binding re-enabled. The tester requested a later Actions and Bindings UI revisit because records read as a continuous text stream rather than distinct scannable items. Unsupported TextInput targets and ambiguous duplicate component-name targets were also excluded as expected. Referenced-variable warning, cancellation, accepted deletion, and unresolved-reference diagnostics also passed without changing unrelated records. Legacy onClick execution, informational diagnostics, and one-way migration to onSuccess also passed; new records did not offer onClick. Failure and ephemeral-state checks passed after fixing the clipped Button error: the complete 503 message is readable, onSuccess withheld the failed response, canonical state remained clean, and a later success cleared the stale error. Save/reload preserved canonical configuration, reset all prior runtime state, and the successful workflow executed after reload. Complete response-binding and variable manual acceptance passed.

Test 3: Page-Load Actions

Status: accepted by the user on 2026-07-29 after the rebuilt Docker Compose workflow passed.

Execute this workflow against the rebuilt Docker Compose application before declaring the page-load increment or Slice 2 accepted:

1. Create an anonymous REST action that returns Dropdown options or Table rows.
2. Assign the existing action to the page's visual onLoad configuration.
3. Add an onSuccess response binding to the Dropdown or Table.
4. Inspect JSON and confirm only canonical page event, action, and binding configuration was added.
5. Enter Preview and verify the action executes once when Preview initializes.
6. Verify loading, successful population, empty results, and failure behavior.
7. Leave and re-enter Preview and verify initialization is predictable and does not write runtime values into canonical JSON.
8. Save and reload the project and repeat the test.
9. Delete the referenced action after accepting its reference warning, or use JSON Editor to create a dangling reference, and verify the Visual Editor shows an actionable missing-action diagnostic.
10. Repeat with an empty successful response and confirm the target presents a usable empty state rather than stale prior data.

Page-load result

• Visual onLoad assignment passed.
• Initial successful population passed.
• Loading, empty, and failure states passed.
• Runtime state remained ephemeral.
• Save/reload passed.
• Missing-reference diagnostics passed.

Tester/date: User, 2026-07-29

Notes or defects: Test 3 passed. The populated Table exposed a non-blocking Preview layout limitation: the white page/canvas background retains its configured or minimum size instead of growing with runtime-rendered Table output. ROADMAP.md tracks content-aware Preview sizing and places Table pagination post-MVP pending a client-side versus server-side design discussion.

Automated checkpoint: 4 focused suites / 9 tests, 18 full frontend suites / 486 tests, frontend production build, and the 13 / 2 / 2 schema matrix passed under Node 20/npm 10 on 2026-07-29. Docker Compose rebuilt, both services started, backend health passed, and the frontend responded on port 3000. Automation and smoke checks do not mark this workflow accepted.

Final Slice 2 Acceptance

Run this only after Tests 1–3 pass and component-deletion diagnostics are complete.

Workflow launcher

1. Build a small form with at least one input, a Button, and a response display.
2. Configure an anonymous action, request reference, Button event, and response binding entirely through visual controls.
3. Execute it successfully in Preview.
4. Trigger a failure and confirm usable error behavior.
5. Save, reload, and execute it again.

Dependent data

1. Populate a Dropdown through a page-load action and response binding.
2. Select a Dropdown value.
3. Use that selection in a second Button-triggered request.
4. Map the second response to another component or variable.
5. Confirm loading, empty, successful, and failed behavior.

Read-only dashboard

1. Populate a Table through a page-load action.
2. Select a row.
3. Display details in a supported response target where the current Slice 2 model allows it.
4. Confirm refresh and failure behavior.

Canonical and persistence regression

1. Inspect JSON after all configuration is complete.
2. Confirm there is no new inputMap and no action.responseMapping behavior.
3. Confirm no credentials or secrets were introduced.
4. Confirm runtime values, loading, responses, and errors are absent.
5. Save and reload the project.
6. Confirm Visual Editor, JSON Editor, Actions & Bindings, and Preview agree.

Final result

• Request-input workflow accepted.
• Response-binding and variable workflow accepted.
• Page-load workflow accepted.
• Workflow launcher passed without routine JSON editing.
• Dependent-data workflow passed.
• Read-only dashboard workflow passed.
• Failure handling passed.
• Canonical synchronization and save/reload passed.

Tester/date: User, 2026-07-30

Notes or defects: The workflow launcher was authored visually with an environment Dropdown, hostname Text Input, Submit Button, JSON Viewer, canonical component templates, Button onClick, and an onSuccess response binding. Successful execution echoed both runtime values; HTTP 503 handling was readable, withheld onSuccess delivery, and cleared its stale error after a successful retry. Dependent-data acceptance used a page onLoad POST to https://httpbingo.org/anything, mapped body.json to Dropdown.options, passed populated and empty states, drove the later launcher request from the selected option, exposed readable failure behavior, and recovered after restoring the successful endpoint. Save/load and fresh Preview preserved canonical configuration while resetting runtime state. No inputMap, action.responseMapping, secrets, responses, loading flags, errors, selected values, or loaded runtime options were persisted. The read-only-dashboard workflow remains a separate pending Slice 6 release workflow.

Page-load diagnostics result

• The page onLoad action no longer reports that it lacks a component or page event.
• Its response binding no longer reports that no component or page event fires the action.

Tester/date: User, 2026-07-30

Notes or defects: The first check displayed the old diagnostics because the browser retained a stale development bundle. A hard refresh loaded the rebuilt frontend, after which both false diagnostics disappeared.

Runtime-expanded Preview background

Purpose: confirm the white Preview page follows runtime content without changing canonical component dimensions.

1. Open the accepted page-load Table project, or configure a page onLoad response binding that supplies enough Table rows to exceed the Table's design-time height.
2. Enter Preview and confirm the white page background extends below all rendered rows with its normal bottom padding.
3. Confirm the outer Preview area remains scrollable when the expanded page exceeds the viewport.
4. Change the successful response to an empty array and re-enter Preview.
5. Confirm the Table shows its usable empty state and the white page contracts to its design-time minimum.
6. Inspect canonical JSON and confirm the Table's configured size.height did not change.

Result: Accepted

• Runtime-populated rows remained inside the white Preview page.
• The expanded page remained scrollable.
• Empty runtime rows produced a usable empty Table and contracted the page.
• Canonical Table size.height remained unchanged.

Tester/date: User, 2026-07-30

MVP component properties and basic appearance

Purpose: confirm the remaining schema-backed properties can be authored visually and render without hand-editing JSON.

1. Select a JSON Viewer, enter valid JSON in Default JSON, and confirm the canvas JSON remains a design placeholder while Preview displays the formatted configured default before any response arrives.
2. Select a Table, set a numeric width on one column, and confirm both the canvas and Preview use that width.
3. Select Text Input, Text Area, and Dropdown components, enable Required, and confirm Preview renders the corresponding controls as required without persisting runtime values.
4. On representative Label, Button, input, Table, Status Panel, and Card components, set Font size, Text, and Background under Basic appearance.
5. Confirm each appearance change immediately updates canonical properties.style, the Visual Editor canvas, and Preview.
6. Reset text and background colors and select the default font size; confirm the overrides are removed from properties.style and default rendering returns.
7. Save and reload, then confirm configured properties persist while runtime state remains reset.

Expected canonical style shape:

{ "fontSize": 20, "textColor": "#112233", "backgroundColor": "#ddeeff" }

Result: Passed on 2026-07-31. The user confirmed all five saved manual sections after Docker rebuild and hard refresh. JSON Viewer defaults, Table widths, required semantics, representative appearance authoring, reset behavior, canonical synchronization, save/reload persistence, and fresh-Preview runtime reset passed. This manual evidence is separate from automated validation.

Slice 2 Actions & Bindings Information Architecture

Purpose: proportionally confirm that the implemented presentation changes make records easier to distinguish without changing configuration behavior.

1. Hard-refresh the rebuilt frontend and open Actions & Bindings in a project with multiple actions, response bindings, and variables.
2. Confirm each record has a distinct boundary and record-type label, and section descriptions clearly distinguish requests, response routing, and runtime variables.
3. Confirm response-binding source/target flow and variable default summaries remain readable.
4. Open action, binding, and variable editors and confirm each editor remains visually attached to the selected record.
5. Edit one record of each type and confirm canonical JSON synchronization and existing diagnostics are unchanged.

Result: Passed on 2026-07-31. The user confirmed distinct section and record hierarchy, readable action/binding/variable summaries, correct editor attachment, canonical edit isolation, and diagnostic placement/recovery. The variable-target check confirmed the canonical variables.statusText target alongside the resolved Variable statusText label.

Slice 2a Request-Reference Usability

Purpose: confirm contextual reference and header-name suggestions improve authoring without changing canonical request behavior.

1. Use a project with one uniquely named Text Input and one declared variable. Edit a REST action and type {{ at the end of the Endpoint URL. Confirm both references appear; choose the component and confirm the canonical {{components.<name>.value}} form is inserted while the URL prefix remains.
2. Repeat after typing {{ in a header value, query-parameter value, and body template. Choose the variable and confirm {{variables.<name>}} is inserted in each field.
3. Create two components with the same name. Confirm that ambiguous component name is absent from contextual suggestions and the guided source list. Restore unique names afterward.
4. Add a header row. Confirm the header-name control suggests Accept and Content-Type, then enter a custom name such as X-Custom-Vendor-Header and confirm it remains accepted in canonical JSON.
5. In Request value reference, confirm the first control is Request destination, the second is Value source, and Insert reference remains last. Confirm a selected Query: <key> aligns conceptually with the query key and the selected component/variable aligns with the request value.
6. Insert one guided reference and confirm existing replace/append behavior remains: header/query values replace; URL/body values append. Confirm path parameters are still excluded.

Result: Passed on 2026-08-01 in isolated Chromium against project Slice 2 Final (#12) at http://localhost:3000/, using 1440 x 1100 and 700 x 1000 viewports. The saved project was not updated. Step 1 contextual suggestions and Steps 2-5 all passed in order. Duplicate component names were excluded until unique, common and custom headers behaved correctly with exact canonical capitalization, guided controls aligned and stacked responsively, canonical component/variable templates were inserted with the required replace/append semantics, path parameters remained excluded, fields remained freely editable, and recursive canonical JSON inspection found no inputMap, responseMapping, runtimeValues, responses, loading, isLoading, errors, or error. This manual evidence is separate from automated validation. The user granted explicit final Slice 2a sign-off on 2026-08-01.

Slice 3 Authentication and Secrets

Purpose: confirm encrypted credential lifecycle authoring, compatible action selection, reference-only canonical state, protected execution, redaction, and deletion safety.

Result: Passed on 2026-08-01 in isolated Chromium against an unsaved browser copy of Slice 2 Final (#12) at http://localhost:3000/. Saved project #12 was not updated.

1. Masked Bearer creation and value replacement passed. Records displayed only name, authentication type, opaque ID, and lifecycle controls; submitted values were cleared and never redisplayed.
2. Basic, Bearer, API-key header, and API-key query choices offered exactly type-compatible secrets. Canonical action state contained only authenticationType and opaque secretReferenceId, with no credential names or values.
3. Preview execution returned HTTP 200 for Bearer, header-key, and query-key checks. Reflected Authorization, header value, query value, and query-bearing URL used [REDACTED]; no stored value reached the browser response.
4. Referenced deletion was blocked with the referencing action named. Changing the action to Anonymous cleared the reference, all disposable secrets were deleted, the server-side list ended empty, and protected mode without a secret did not send a proxy request or execute anonymously.

The tester observed that the earlier blocked-deletion warning remained visible after successful cleanup. This did not affect lifecycle operations or execution safety and is tracked as a non-blocking error-feedback follow-up in ROADMAP.md. This manual evidence is separate from automated validation. The user granted explicit final Slice 3 sign-off on 2026-08-02.

Recording Results

After a manual workflow is completed:

1. Update its checkboxes in this document.

2. Record the tester, date, environment, and any deviations.

3. Record manual acceptance separately from automated coverage in:

   • CODEX.md
   • SLICE2.md
   • BASELINE.md

4. Do not mark a broader workflow accepted when only one checkpoint passed.

5. File unresolved defects in ROADMAP.md and the owning slice with enough detail to reproduce them.