710 lines
40 KiB
Markdown
710 lines
40 KiB
Markdown
# 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 6a Progressive Disclosure Gate — 2026-08-07
|
||
|
||
Actions & Bindings now uses accessible collapsible major sections and independently collapsible action, binding, variable, and secret cards. REST editing is grouped into Identity, Endpoint & authentication, Request parameters, and Request body; the denser request groups start closed. Secret creation is explicit rather than exposing its full form whenever the section opens. Section hiding preserves mounted local editor state, and collapsed issue badges lead to expanded diagnostics.
|
||
|
||
Focused ActionInspector/SecretManager coverage passes at 18 tests. Full frontend coverage passes at 25 suites / 520 tests, standalone TypeScript passes, and the production build succeeds. Standard Compose was rebuilt successfully. A disposable high-density project, `Slice 6a Density Manual` (`#22`), is prepared for the proportional procedure in `SLICE6a_MANUAL_TEST.md`. Manual acceptance, cleanup, and explicit sign-off remain pending.
|
||
|
||
The user subsequently reported all five manual UX tests pass and that the changes look good. Cleanup deleted project `#22`, and final standard-stack checks returned backend health `ok`, frontend HTTP 200, empty secrets, and empty execution history.
|
||
|
||
The user granted explicit final Slice 6a sign-off on 2026-08-07 with the exact wording: “I grant explicit final Slice 6a sign-off.” Slice 6a is complete.
|
||
|
||
## Slice 7 MVP Governance Reconciliation — 2026-08-07
|
||
|
||
The already approved Slice 7 product decisions were reconciled across `README.md`, `MVP_SCOPE.md`, `ROADMAP.md`, `docs/REQUIREMENTS.md`, and `docs/ARCHITECTURE.md`. Stale AI-MVP claims and material open questions were removed; implemented proxy, secrets, authentication, observability, canonical-model, timeout, event, binding, and editor decisions now use consistent language. All six `MVP_SCOPE.md` workflow checklists reflect accepted Slice 6 evidence.
|
||
|
||
`docs/MVP_TRACEABILITY.md` maps 14 release-critical requirement areas and all six workflows to owning slices and validation evidence, and explicitly classifies deferred capabilities post-MVP. `npm run test:governance` passes, checking authority statements, accepted workflow state, forbidden stale claims, Slice 7 roadmap status, R1–R14 coverage, and relative documentation links. No new product behavior or manual test gate was introduced; the release boundary already has product-owner approval.
|
||
|
||
The product owner subsequently added Slice 7a local authentication/RBAC and standalone application publishing to the pre-Slice-8 v0.1 boundary. Traceability now includes planned R15–R16. Slice 9 reserves post-v0.1 OIDC/SSO and must reuse Slice 7a's provider-neutral principal/session/capability architecture. The governance check now requires R1–R16.
|
||
|
||
## 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:
|
||
|
||
```bash
|
||
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:
|
||
|
||
```bash
|
||
docker compose up --build
|
||
```
|
||
|
||
Leave this terminal running. In another terminal, run:
|
||
|
||
```bash
|
||
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:
|
||
|
||
```bash
|
||
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:
|
||
|
||
```text
|
||
{{components.itemInput.value}}
|
||
```
|
||
|
||
10. Open **JSON Editor** and find the action's `queryParameters`.
|
||
|
||
Expected canonical fragment:
|
||
|
||
```json
|
||
"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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```text
|
||
?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:
|
||
|
||
```text
|
||
{{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
|
||
|
||
- [x] Docker services and health endpoint passed.
|
||
- [x] Guided `item` query-reference insertion looked correct (2026-07-20).
|
||
- [x] Canonical component template and absence of `inputMap` confirmed.
|
||
- [x] Path parameters confirmed absent from guided destinations.
|
||
- [x] Runtime component value appeared in the outgoing request.
|
||
- [x] Runtime state remained absent from canonical JSON.
|
||
- [x] Raw template editing regression passed.
|
||
- [x] 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:
|
||
|
||
```json
|
||
{"source":"manual"}
|
||
```
|
||
|
||
7. Create `items` with type `array` and default:
|
||
|
||
```json
|
||
[]
|
||
```
|
||
|
||
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
|
||
|
||
- [x] Typed variable declarations/defaults passed.
|
||
- [x] Invalid variable draft remained outside canonical JSON.
|
||
- [x] Component response binding executed with `onSuccess`.
|
||
- [x] Variable response binding executed without changing its canonical default.
|
||
- [x] Binding edit and delete passed.
|
||
- [x] Unsupported and ambiguous targets were excluded.
|
||
- [x] Referenced-variable deletion warning passed.
|
||
- [x] Legacy `onClick` compatibility and one-way migration passed.
|
||
- [x] Failure and ephemeral-state checks passed.
|
||
- [x] 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
|
||
|
||
- [x] Visual `onLoad` assignment passed.
|
||
- [x] Initial successful population passed.
|
||
- [x] Loading, empty, and failure states passed.
|
||
- [x] Runtime state remained ephemeral.
|
||
- [x] Save/reload passed.
|
||
- [x] 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
|
||
|
||
- [x] Request-input workflow accepted.
|
||
- [x] Response-binding and variable workflow accepted.
|
||
- [x] Page-load workflow accepted.
|
||
- [x] Workflow launcher passed without routine JSON editing.
|
||
- [x] Dependent-data workflow passed.
|
||
- [ ] Read-only dashboard workflow passed.
|
||
- [x] Failure handling passed.
|
||
- [x] 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
|
||
|
||
- [x] The page `onLoad` action no longer reports that it lacks a component or page event.
|
||
- [x] 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
|
||
|
||
- [x] Runtime-populated rows remained inside the white Preview page.
|
||
- [x] The expanded page remained scrollable.
|
||
- [x] Empty runtime rows produced a usable empty Table and contracted the page.
|
||
- [x] 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:
|
||
|
||
```json
|
||
{ "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.
|