246 lines
12 KiB
Markdown
246 lines
12 KiB
Markdown
# Conductor Save Point — 2026-07-31
|
||
|
||
## Purpose
|
||
|
||
Resume Conductor at `/home/vwiebe/projects/conductor`, finish the remaining Slice 2a proportional manual step tests, record the results separately from automation, and obtain explicit Slice 2a sign-off before moving to another slice.
|
||
|
||
Do not commit or push without explicit authorization. Preserve the intentional documentation consolidation and all unrelated working-tree changes. Do not restore deliberately deleted root documents. Runtime state must remain separate from canonical project JSON.
|
||
|
||
## Resume Checklist
|
||
|
||
Read, in order:
|
||
|
||
1. `SAVE_073126.md`
|
||
2. `ROADMAP.md`
|
||
3. `SLICE2a.md`
|
||
4. `SLICE2.md`
|
||
5. `CODEX.md`
|
||
6. `TESTING.md`
|
||
7. `BASELINE.md`
|
||
8. `MVP_SCOPE.md`
|
||
|
||
Then run:
|
||
|
||
```bash
|
||
git status --short --branch
|
||
git log --oneline -5
|
||
git diff --check
|
||
docker compose ps
|
||
docker compose exec -T backend wget -qO- http://localhost:4000/api/health
|
||
```
|
||
|
||
Expected pushed baseline:
|
||
|
||
- Branch: `main`
|
||
- `main` and `origin/main`: `86ca42a Add page-load actions and component deletion safeguards`
|
||
- Everything described below remains intentionally uncommitted and unpushed.
|
||
|
||
## Working-Tree Boundaries
|
||
|
||
Preserve the existing documentation consolidation:
|
||
|
||
- `ROADMAP.md` is the master work index.
|
||
- `SLICE2a.md` owns the current request-reference usability increment.
|
||
- Authoritative requirement, architecture, and future-idea documents are under `docs/`.
|
||
- Root duplicate specifications and `TASKS.md`, `NEXT_SESSION_PROMPT.md`, and `SAFETY_TEST_PLAN.md` were deliberately removed.
|
||
- Do not restore deleted files or overwrite unrelated modified documentation.
|
||
|
||
Do not add path-parameter reference insertion, authentication/secret references, new template syntax, transforms, orchestration, or Table pagination. These remain outside Slice 2a.
|
||
|
||
## Slice 2 Status
|
||
|
||
Slice 2 is complete and explicitly signed off by the user on 2026-07-31.
|
||
|
||
Completed Slice 2 evidence includes:
|
||
|
||
- final workflow-launcher and dependent-data acceptance;
|
||
- page `onLoad` diagnostics correction;
|
||
- runtime-aware Preview canvas sizing;
|
||
- JSON Viewer defaults, Table column widths, required inputs, and basic appearance;
|
||
- Actions & Bindings information-architecture improvements;
|
||
- the documented fixed 30-second backend timeout contract;
|
||
- consolidated automated validation, Docker health, documentation reconciliation, and proportional manual acceptance.
|
||
|
||
Do not reopen Slice 2 unless a concrete regression is found.
|
||
|
||
## Current Slice 2a Implementation
|
||
|
||
Slice 2a is implemented, automated validation passes, Docker has been rebuilt, and proportional manual acceptance is in progress.
|
||
|
||
Implemented behavior:
|
||
|
||
- Endpoint URL, header-value, query-value, and body-template fields show compatible component and variable suggestions after an unfinished `{{` opener.
|
||
- Selecting a suggestion replaces the unfinished opener/partial expression while preserving preceding free-form text.
|
||
- Suggestions insert only the canonical executed forms:
|
||
- `{{components.<componentName>.value}}`
|
||
- `{{variables.<variableName>}}`
|
||
- Components with ambiguous duplicate names are excluded from contextual suggestions and the guided source list.
|
||
- Header-name inputs suggest common names including `Accept` and `Content-Type` while accepting arbitrary custom names.
|
||
- **Request value reference** now presents controls in this order:
|
||
1. **Request destination**
|
||
2. **Value source**
|
||
3. **Insert reference**
|
||
- Existing guided semantics remain unchanged: header/query destinations replace the selected value, while URL/body destinations append.
|
||
- Path parameters remain excluded from guided and contextual template insertion.
|
||
- Canonical request shapes and Preview runtime behavior are unchanged.
|
||
|
||
Material Slice 2a files:
|
||
|
||
- `frontend/src/components/ActionInspector/TemplateSuggestions.tsx`
|
||
- `frontend/src/components/ActionInspector/TemplateSuggestions.test.tsx`
|
||
- `frontend/src/components/ActionInspector/RestActionEditor.tsx`
|
||
- `frontend/src/components/ActionInspector/RequestInputEditor.tsx`
|
||
- `frontend/src/components/ActionInspector/RequestInputEditor.test.tsx`
|
||
- `frontend/src/components/ActionInspector/requestInputUtils.ts`
|
||
- `frontend/src/components/ActionInspector/requestInputUtils.test.ts`
|
||
- `frontend/src/components/ActionInspector/ActionInspector.module.css`
|
||
- `frontend/src/components/ActionInspector/ActionInspector.test.tsx`
|
||
- `SLICE2a.md`, `ROADMAP.md`, `TESTING.md`, `CODEX.md`, and other status/evidence documents
|
||
|
||
## Current Automated Validation
|
||
|
||
All passed under the documented Node 20/npm 10 toolchain:
|
||
|
||
- Focused Slice 2a request-authoring coverage: 4 suites / 23 tests.
|
||
- Complete frontend coverage: 21 suites / 507 tests, 0 snapshots.
|
||
- Frontend production build.
|
||
- `git diff --check`.
|
||
- Docker Compose rebuild.
|
||
- Both Docker services running.
|
||
- Backend health returned `status: ok`.
|
||
- Frontend returned HTTP 200.
|
||
|
||
Backend build and schema validation were not rerun for Slice 2a because this increment changes frontend authoring behavior only and preserves the canonical document shape. The earlier Slice 2 consolidated backend build and 13-valid / 2-expected-invalid / 2-diagnostic-invalid schema matrix passed.
|
||
|
||
Standalone frontend `tsc --noEmit` retains the existing TypeScript 4.9 / `@types/node@26.1.0` incompatibility and remains separate from the passing CRA production compile.
|
||
|
||
## Manual Acceptance Status
|
||
|
||
### Step 1 — Contextual suggestions: PASSED
|
||
|
||
The user confirmed the detailed contextual-suggestion procedure on 2026-07-31.
|
||
|
||
The accepted check used:
|
||
|
||
- a uniquely named Text Input such as `hostname`;
|
||
- a declared string variable such as `environment`;
|
||
- an Endpoint URL ending in an unfinished `{{` opener;
|
||
- component and variable suggestion visibility;
|
||
- selection of canonical component/variable templates;
|
||
- preservation of the text preceding `{{`;
|
||
- equivalent suggestion behavior in URL, header value, query value, and body template fields.
|
||
|
||
Do not repeat Step 1 unless a regression is suspected.
|
||
|
||
### Remaining manual tests
|
||
|
||
Four step tests remain. Give the user exact point-and-click instructions one step at a time. Do not combine them into a vague checklist. Wait for confirmation after each step.
|
||
|
||
#### Step 2 — Ambiguous duplicate component names
|
||
|
||
1. In **Visual Editor**, ensure one Text Input is named `hostname`.
|
||
2. Add a second Text Input and also name it `hostname`.
|
||
3. Return to **Actions & Bindings** and edit the REST action.
|
||
4. In a supported request value field, replace the value with exactly `{{`.
|
||
5. Confirm `Component: hostname` is absent from the contextual suggestion panel.
|
||
6. Open **Value source** under **Request value reference** and confirm `Component: hostname` is absent there too.
|
||
7. Confirm a valid declared variable such as `Variable: environment` remains offered.
|
||
8. Rename the second component to `hostnameSecondary`.
|
||
9. Return to the action, type `{{` again, and confirm both unique components are offered.
|
||
|
||
Pass: the ambiguous name is withheld in both suggestion mechanisms and reappears only after names become unique.
|
||
|
||
#### Step 3 — Common and custom header names
|
||
|
||
1. Edit a REST action and open **Request parameters**.
|
||
2. Under **Headers**, click **+ Add row**.
|
||
3. Focus the header-name field or begin typing.
|
||
4. Confirm `Accept` and `Content-Type` are offered by the header-name suggestions.
|
||
5. Enter the custom name `X-Custom-Vendor-Header` instead.
|
||
6. Enter any value, such as `test`.
|
||
7. Inspect canonical JSON and confirm the header is stored exactly as entered.
|
||
|
||
Pass: common names are suggested, custom entry remains possible, and the canonical header object is unchanged in shape.
|
||
|
||
#### Step 4 — Guided-control order and alignment
|
||
|
||
1. Edit a REST action containing a query parameter such as `environment`.
|
||
2. Locate **Request value reference**.
|
||
3. Confirm the visible order is **Request destination**, **Value source**, **Insert reference**.
|
||
4. In **Request destination**, select `Query: environment`.
|
||
5. In **Value source**, select `Variable: environment` or a unique component.
|
||
6. Confirm the destination control aligns with the request-key side of the query row and the value-source control aligns with the request-value side at the current viewport.
|
||
7. Click **Insert reference** and confirm the expected canonical template appears in the query value.
|
||
8. Narrow the browser window to a supported small width and confirm the controls stack clearly without overlap.
|
||
|
||
Pass: order, conceptual key/value alignment, responsive stacking, and insertion are clear.
|
||
|
||
#### Step 5 — Existing behavior regression
|
||
|
||
1. Use guided insertion into an existing header value and confirm the old value is replaced.
|
||
2. Use guided insertion into an existing query value and confirm the old value is replaced.
|
||
3. Use guided insertion into an Endpoint URL and confirm the template is appended.
|
||
4. Use guided insertion into a non-empty body template and confirm the template is appended.
|
||
5. Confirm path parameters are not offered as guided destinations and do not show contextual template suggestions.
|
||
6. After any insertion, type additional free-form text and confirm editing remains possible.
|
||
7. Inspect canonical JSON and confirm no `inputMap`, `action.responseMapping`, runtime values, responses, loading flags, or errors were added.
|
||
|
||
Pass: all previous replace/append behavior and canonical/runtime separation remain intact.
|
||
|
||
## After Manual Testing
|
||
|
||
If a defect is found:
|
||
|
||
1. Record the exact failed step and observed behavior.
|
||
2. Reproduce it narrowly.
|
||
3. Fix only the affected Slice 2a authoring path.
|
||
4. Add focused coverage.
|
||
5. Rerun the focused suites, complete frontend suite, frontend production build, `git diff --check`, Docker rebuild, and the failed manual step plus proportional regressions.
|
||
|
||
If Steps 2–5 pass:
|
||
|
||
1. Update `SLICE2a.md`, `ROADMAP.md`, `TESTING.md`, `BASELINE.md`, and `CODEX.md` with manual evidence separate from automation.
|
||
2. Run final `git diff --check`, `docker compose ps`, and backend health.
|
||
3. Ask the user for explicit final Slice 2a sign-off.
|
||
4. Do not commit or push without explicit authorization.
|
||
|
||
## Current Commit and Service State
|
||
|
||
- Branch: `main`, aligned with `origin/main` at `86ca42a`.
|
||
- The working tree is intentionally dirty with the documented consolidation, completed Slice 2 work, and current Slice 2a increment.
|
||
- Nothing from these increments has been committed or pushed.
|
||
- Docker frontend and backend services were running and healthy when this save point was created.
|
||
- `git diff --check` passed.
|
||
|
||
## Complete Continuation Prompt
|
||
|
||
Copy and paste the following prompt into a future session:
|
||
|
||
```text
|
||
Please resume Conductor from /home/vwiebe/projects/conductor using SAVE_073126.md as the authoritative current-session handoff.
|
||
|
||
Read SAVE_073126.md first, then follow its resume checklist. Preserve all intentional documentation consolidation and unrelated working-tree changes. Do not restore deliberately deleted root documents. Do not commit or push without my explicit authorization.
|
||
|
||
Slice 2 is complete and explicitly signed off. Slice 2a is implemented and automated validation passes. Manual Slice 2a Step 1 (contextual suggestions) has passed. Continue with the four remaining proportional manual tests, beginning with Step 2 (ambiguous duplicate component names).
|
||
|
||
Please give me exact, detailed, point-and-click instructions for only one manual step at a time, including concrete field names, example values, and precise expected results. Wait for my confirmation after each step before presenting the next one. If a test fails, reproduce and fix only the affected Slice 2a path, add focused coverage, and rerun proportional validation. If Steps 2 through 5 pass, reconcile SLICE2a.md, ROADMAP.md, TESTING.md, BASELINE.md, and CODEX.md, run final integrity and Docker health checks, and ask me for explicit Slice 2a sign-off.
|
||
```
|
||
|
||
## Final Safety Checks
|
||
|
||
Before ending the resumed session, report separately:
|
||
|
||
- implemented changes;
|
||
- automated validation;
|
||
- each manual step result;
|
||
- remaining blockers or gates;
|
||
- Docker/service state;
|
||
- commit/push state.
|
||
|
||
Always run:
|
||
|
||
```bash
|
||
git diff --check
|
||
git status --short --branch
|
||
```
|