Establish validated MVP baseline
This commit is contained in:
parent
aa9cfb4ff0
commit
d1c1ce9270
105
BASELINE.md
Normal file
105
BASELINE.md
Normal file
@ -0,0 +1,105 @@
|
|||||||
|
# Validation Baseline
|
||||||
|
|
||||||
|
## Date
|
||||||
|
|
||||||
|
2026-07-18
|
||||||
|
|
||||||
|
## Environment
|
||||||
|
|
||||||
|
- Target toolchain: Node.js 20 and npm 10
|
||||||
|
- Executed toolchain: Node.js 20.20.2 and npm 10.9.8, supplied ephemerally through `npx`
|
||||||
|
- Docker CLI: available on Windows
|
||||||
|
- Docker engine: unavailable because Docker Desktop's Linux engine was not running
|
||||||
|
- Docker inside WSL: unavailable because WSL integration was disabled
|
||||||
|
|
||||||
|
## Dependency Installation
|
||||||
|
|
||||||
|
- Root `npm ci`: passed under the preinstalled WSL Node 18/npm 9 toolchain; reported 2 high-severity audit findings in `ajv-cli` dependencies.
|
||||||
|
- Frontend clean install initially failed because `frontend/package-lock.json` was missing `yaml@2.9.0`.
|
||||||
|
- `npm install --package-lock-only` under Node 20/npm 10 repaired the frontend lockfile.
|
||||||
|
- Frontend clean install then passed under Node 20/npm 10; npm reported 28 dependency vulnerabilities: 9 low, 6 moderate, and 13 high.
|
||||||
|
- Backend clean install passed under Node 20/npm 10; npm reported 0 vulnerabilities.
|
||||||
|
|
||||||
|
## Automated Checks
|
||||||
|
|
||||||
|
### Frontend tests
|
||||||
|
|
||||||
|
Command:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx --yes --package=node@20 --package=npm@10 npm test -- --watchAll=false --runInBand
|
||||||
|
```
|
||||||
|
|
||||||
|
Result: Passed.
|
||||||
|
|
||||||
|
- Test suites: 6 passed, 6 total
|
||||||
|
- Tests: 420 passed, 420 total
|
||||||
|
- Snapshots: 0
|
||||||
|
|
||||||
|
### Frontend production build
|
||||||
|
|
||||||
|
Command:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx --yes --package=node@20 --package=npm@10 npm run build
|
||||||
|
```
|
||||||
|
|
||||||
|
Result: Passed.
|
||||||
|
|
||||||
|
### Backend TypeScript build
|
||||||
|
|
||||||
|
Command:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx --yes --package=node@20 --package=npm@10 npm run build
|
||||||
|
```
|
||||||
|
|
||||||
|
Result: Passed.
|
||||||
|
|
||||||
|
## Schema Matrix
|
||||||
|
|
||||||
|
Eleven `valid-*.json` project definitions passed validation against `shared/schemas/conductor-project.schema.json`.
|
||||||
|
|
||||||
|
Two schema-invalid fixtures failed validation as expected:
|
||||||
|
|
||||||
|
- `invalid-dropdown-option-shape.json`
|
||||||
|
- `invalid-missing-required.json`
|
||||||
|
|
||||||
|
Two diagnostic-invalid fixtures passed structural schema validation as designed because their defects require semantic/runtime diagnostics:
|
||||||
|
|
||||||
|
- `invalid-template-malformed.json`
|
||||||
|
- `invalid-template-missing-component.json`
|
||||||
|
|
||||||
|
## Runtime Startup
|
||||||
|
|
||||||
|
Initial backend startup against a clean SQLite database failed with:
|
||||||
|
|
||||||
|
```text
|
||||||
|
SqliteError: no such table: projects
|
||||||
|
```
|
||||||
|
|
||||||
|
Cause: `backend/src/index.ts` statically imported `app` before calling `initDatabase()`. Importing the app loaded project routes and prepared SQL statements before the `projects` table existed.
|
||||||
|
|
||||||
|
Fix: run `initDatabase()` first, then dynamically import the Express app and start listening.
|
||||||
|
|
||||||
|
After the fix, clean-database startup, HTTP health, complete CRUD, cleanup, and persistence across a backend container restart all passed.
|
||||||
|
|
||||||
|
## Docker Validation
|
||||||
|
|
||||||
|
Docker Desktop was started and validation completed. Both images built, both services started, the frontend compiled, the backend initialized SQLite, and health, CRUD, cleanup, and restart-persistence checks passed.
|
||||||
|
|
||||||
|
## Baseline Status
|
||||||
|
|
||||||
|
Passing for the current automated and Docker smoke-test scope:
|
||||||
|
|
||||||
|
- [x] Locked frontend dependencies repaired
|
||||||
|
- [x] Frontend tests pass
|
||||||
|
- [x] Frontend production build passes
|
||||||
|
- [x] Backend TypeScript build passes
|
||||||
|
- [x] Schema matrix behaves as expected
|
||||||
|
- [x] Backend starts against a clean database
|
||||||
|
- [x] Health and CRUD smoke checks pass
|
||||||
|
- [x] Persistence survives a backend container restart
|
||||||
|
- [x] Docker Compose build and integration checks pass
|
||||||
|
|
||||||
|
Remaining release work includes broader backend tests, browser end-to-end tests, security regression tests, and resolution of the frontend dependency audit findings.
|
||||||
29
CODEX.md
29
CODEX.md
@ -108,7 +108,9 @@ The following MVP component types are accepted by the schema but are not active
|
|||||||
- Project documents are validated in the JSON Editor, but save operations still need an unconditional validation gate.
|
- Project documents are validated in the JSON Editor, but save operations still need an unconditional validation gate.
|
||||||
- The schema accepts five component types that the editor and runtime cannot render.
|
- The schema accepts five component types that the editor and runtime cannot render.
|
||||||
- Backend and end-to-end automated test coverage remains incomplete.
|
- Backend and end-to-end automated test coverage remains incomplete.
|
||||||
- The requirements include IBM Bob/watsonx in MVP scope, while the architecture permits operation without AI. The release requirement still needs a decision.
|
- IBM Bob/watsonx will not be used; AI is provider-neutral and post-MVP.
|
||||||
|
- All five modeled authentication modes are required for MVP.
|
||||||
|
- MVP completion is defined by the six workflows in `MVP_SCOPE.md`.
|
||||||
- Root-level requirement and architecture documents duplicate files under `docs/` and may drift.
|
- Root-level requirement and architecture documents duplicate files under `docs/` and may drift.
|
||||||
|
|
||||||
## Validation Status
|
## Validation Status
|
||||||
@ -118,23 +120,24 @@ The initial repository push was completed on 2026-07-18.
|
|||||||
- Remote `main` contains commit `cce97392f72049007cf00b0aa6c77fb8c8256191`.
|
- Remote `main` contains commit `cce97392f72049007cf00b0aa6c77fb8c8256191`.
|
||||||
- The working tree was clean immediately after the push.
|
- The working tree was clean immediately after the push.
|
||||||
- All `:Zone.Identifier` sidecar files were removed before the initial commit.
|
- All `:Zone.Identifier` sidecar files were removed before the initial commit.
|
||||||
- Frontend tests, frontend build, and backend build were attempted before the push but could not start because dependencies were not installed locally (`react-scripts` and `tsc` were unavailable).
|
- Node 20/npm 10 clean installs pass after repairing the frontend lockfile.
|
||||||
- Do not treat the current codebase as freshly validated until dependencies are installed and the validation suite is run.
|
- Frontend validation passes: 6 suites and 420 tests, plus the production build.
|
||||||
|
- Backend build and the schema fixture matrix pass.
|
||||||
|
- Docker Compose builds and starts both services.
|
||||||
|
- Health, CRUD, cleanup, and restart persistence pass.
|
||||||
|
- See `BASELINE.md` for exact evidence and remaining release work.
|
||||||
|
|
||||||
## Immediate Priorities
|
## Immediate Priorities
|
||||||
|
|
||||||
Unless the user chooses a different priority, proceed in this order:
|
Unless the user chooses a different priority, proceed in this order:
|
||||||
|
|
||||||
1. Install dependencies using the repository lockfiles and run the existing validation suite.
|
1. Implement the five missing MVP GUI components individually, with tests.
|
||||||
2. Record genuine failures separately from environment/setup failures.
|
2. Add visual REST action, event, and binding configuration.
|
||||||
3. Implement the five missing MVP GUI components individually, with tests.
|
3. Add validation to every project save path.
|
||||||
4. Add visual REST action, event, and binding configuration.
|
4. Implement authentication and secure secret handling.
|
||||||
5. Add validation to every project save path.
|
5. Harden the REST proxy and add sanitized execution logging.
|
||||||
6. Implement authentication and secure secret handling.
|
6. Add backend, end-to-end, and security regression tests.
|
||||||
7. Harden the REST proxy and add sanitized execution logging.
|
7. Reconcile and consolidate project documentation.
|
||||||
8. Add backend and end-to-end tests, then complete Docker Compose validation.
|
|
||||||
9. Resolve the AI-in-MVP scope decision.
|
|
||||||
10. Reconcile and consolidate project documentation.
|
|
||||||
|
|
||||||
See `TASKS.md` for the complete actionable checklist.
|
See `TASKS.md` for the complete actionable checklist.
|
||||||
|
|
||||||
|
|||||||
75
MVP_SCOPE.md
Normal file
75
MVP_SCOPE.md
Normal file
@ -0,0 +1,75 @@
|
|||||||
|
# Conductor MVP Scope
|
||||||
|
|
||||||
|
## Status
|
||||||
|
|
||||||
|
Approved on 2026-07-18.
|
||||||
|
|
||||||
|
## AI Decision
|
||||||
|
|
||||||
|
IBM Bob and watsonx will not be used. The initial MVP has no AI dependency. Any future AI integration must be provider-neutral and is post-MVP.
|
||||||
|
|
||||||
|
## Required Authentication Types
|
||||||
|
|
||||||
|
All five authentication types currently defined by the project schema are required for MVP release:
|
||||||
|
|
||||||
|
- Anonymous
|
||||||
|
- Basic authentication
|
||||||
|
- Bearer token
|
||||||
|
- API key in a request header
|
||||||
|
- API key in a query parameter
|
||||||
|
|
||||||
|
Credentials must be resolved and injected by the backend. They must not appear in canonical project JSON, exports, browser-visible configuration, or unsanitized logs.
|
||||||
|
|
||||||
|
## MVP Acceptance Workflows
|
||||||
|
|
||||||
|
These are end-to-end acceptance scenarios. They demonstrate that Conductor can build and run REST-backed interfaces; they do not make Conductor a workflow-orchestration engine.
|
||||||
|
|
||||||
|
### 1. Workflow Launcher
|
||||||
|
|
||||||
|
- [ ] Create a project.
|
||||||
|
- [ ] Add an environment dropdown, hostname input, Submit button, and response display.
|
||||||
|
- [ ] Define a REST action.
|
||||||
|
- [ ] Map component values into the request.
|
||||||
|
- [ ] Bind the button to the action and map the response to the display.
|
||||||
|
- [ ] Execute the scenario successfully in Preview.
|
||||||
|
- [ ] Save, reload, and confirm the complete behavior is preserved.
|
||||||
|
|
||||||
|
### 2. Dependent Data
|
||||||
|
|
||||||
|
- [ ] Call an API to populate a dropdown.
|
||||||
|
- [ ] Use its selected value to populate or update another component.
|
||||||
|
- [ ] Confirm loading, empty, and failure states are usable.
|
||||||
|
|
||||||
|
### 3. Read-Only Dashboard
|
||||||
|
|
||||||
|
- [ ] Call an API and populate a table.
|
||||||
|
- [ ] Select a table row.
|
||||||
|
- [ ] Display the selected record's details in another component.
|
||||||
|
- [ ] Confirm refresh and error behavior.
|
||||||
|
|
||||||
|
### 4. Authenticated Request
|
||||||
|
|
||||||
|
- [ ] Configure and execute each of the five required authentication modes.
|
||||||
|
- [ ] Confirm credentials are injected only by the backend.
|
||||||
|
- [ ] Confirm secrets do not appear in browser-visible data, project JSON, exports, errors, or logs.
|
||||||
|
|
||||||
|
### 5. JSON Editing and Persistence
|
||||||
|
|
||||||
|
- [ ] Edit canonical project JSON.
|
||||||
|
- [ ] Validate and apply it.
|
||||||
|
- [ ] Confirm the Visual Editor updates to match.
|
||||||
|
- [ ] Save and reload the project without structural or behavioral loss.
|
||||||
|
|
||||||
|
### 6. Failure Handling
|
||||||
|
|
||||||
|
- [ ] Trigger an invalid request.
|
||||||
|
- [ ] Trigger an invalid or unresolved response mapping.
|
||||||
|
- [ ] Receive actionable errors in the appropriate UI.
|
||||||
|
- [ ] Confirm canonical project state is not corrupted.
|
||||||
|
- [ ] Confirm unsaved work is not lost.
|
||||||
|
|
||||||
|
## Release Boundary
|
||||||
|
|
||||||
|
The MVP is complete only when all required component, configuration, authentication, security, validation, persistence, and deployment tasks in `TASKS.md` are complete and all six workflows above pass the Slice 6 release-validation process.
|
||||||
|
|
||||||
|
Post-MVP scope includes AI assistance, OAuth 2.0, IBM Cloud IAM, mTLS, advanced orchestration, and the future GUI components listed in `TASKS.md`.
|
||||||
27
SLICE6.md
27
SLICE6.md
@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
## Status
|
## Status
|
||||||
|
|
||||||
Not started
|
In progress
|
||||||
|
|
||||||
## Objective
|
## Objective
|
||||||
|
|
||||||
@ -24,16 +24,16 @@ Produce repeatable automated and manual evidence that the complete MVP builds, r
|
|||||||
|
|
||||||
## Tasks
|
## Tasks
|
||||||
|
|
||||||
- [ ] Install dependencies from lockfiles and document the supported toolchain.
|
- [x] Install dependencies from lockfiles and document the supported toolchain.
|
||||||
- [ ] Establish clean frontend and backend validation commands.
|
- [x] Establish clean frontend and backend validation commands.
|
||||||
- [ ] Define release-critical coverage and test layers.
|
- [ ] Define release-critical coverage and test layers.
|
||||||
- [ ] Complete frontend component, editor, binding, and Preview tests.
|
- [ ] Complete frontend component, editor, binding, and Preview tests.
|
||||||
- [ ] Complete backend CRUD, validation, authentication, proxy, security, and persistence tests.
|
- [ ] Complete backend CRUD, validation, authentication, proxy, security, and persistence tests.
|
||||||
- [ ] Add canonical-document persistence round-trip tests.
|
- [ ] Add canonical-document persistence round-trip tests.
|
||||||
- [ ] Add workflow-launcher, dependent-dropdown, and dashboard end-to-end scenarios.
|
- [ ] Add workflow-launcher, dependent-dropdown, and dashboard end-to-end scenarios.
|
||||||
- [ ] Validate all valid and invalid examples.
|
- [x] Validate all valid and invalid examples.
|
||||||
- [ ] Produce successful frontend and backend production builds.
|
- [x] Produce successful frontend and backend production builds.
|
||||||
- [ ] Verify full-stack Docker Compose startup, health, restart, and persistence.
|
- [x] Verify full-stack Docker Compose startup, health, restart, and persistence.
|
||||||
- [ ] Run the final security regression suite.
|
- [ ] Run the final security regression suite.
|
||||||
- [ ] Record commands, test counts, artifacts, limitations, and defects.
|
- [ ] Record commands, test counts, artifacts, limitations, and defects.
|
||||||
- [ ] Update state and the final acceptance checklist.
|
- [ ] Update state and the final acceptance checklist.
|
||||||
@ -61,10 +61,17 @@ Produce repeatable automated and manual evidence that the complete MVP builds, r
|
|||||||
|
|
||||||
## Progress Log
|
## Progress Log
|
||||||
|
|
||||||
No work recorded yet.
|
### 2026-07-18
|
||||||
|
|
||||||
|
- Repaired the frontend lockfile and completed Node 20/npm 10 clean installs.
|
||||||
|
- Passed 6 frontend suites with 420 tests.
|
||||||
|
- Passed frontend and backend production builds and the schema fixture matrix.
|
||||||
|
- Fixed clean-database backend startup ordering.
|
||||||
|
- Passed Docker build, startup, health, CRUD, cleanup, and restart persistence.
|
||||||
|
- Recorded exact evidence in `BASELINE.md`.
|
||||||
|
|
||||||
## Handoff
|
## Handoff
|
||||||
|
|
||||||
- Last completed: Slice plan created.
|
- Last completed: Initial technical and Docker validation baseline.
|
||||||
- Next action: Install locked dependencies and record the first full baseline.
|
- Next action: Continue release validation as each implementation slice completes.
|
||||||
- Known blockers: Final validation depends on Slices 1-5 and the Slice 7 decision.
|
- Known blockers: Final validation depends on Slices 1-5; frontend audit findings remain open.
|
||||||
|
|||||||
31
SLICE7.md
31
SLICE7.md
@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
## Status
|
## Status
|
||||||
|
|
||||||
Not started
|
Complete
|
||||||
|
|
||||||
## Objective
|
## Objective
|
||||||
|
|
||||||
@ -25,15 +25,13 @@ Define one testable MVP release boundary, especially whether IBM Bob/watsonx int
|
|||||||
|
|
||||||
## Tasks
|
## Tasks
|
||||||
|
|
||||||
- [ ] Inventory ambiguous or conflicting MVP statements.
|
- [x] Inventory ambiguous or conflicting MVP statements.
|
||||||
- [ ] Define minimum release personas and workflows.
|
- [x] Define minimum release workflows.
|
||||||
- [ ] Decide whether AI is required, optional, or post-MVP.
|
- [x] Decide that AI is provider-neutral and post-MVP.
|
||||||
- [ ] If required, define the smallest acceptable AI capability and provider boundary.
|
- [x] Decide that every modeled authentication type is release-blocking.
|
||||||
- [ ] Decide whether every modeled authentication type is release-blocking.
|
- [x] Confirm the six acceptance workflows in `MVP_SCOPE.md`.
|
||||||
- [ ] Confirm component, lifecycle, persistence, export, observability, and deployment expectations.
|
- [x] Convert the decisions into measurable release criteria.
|
||||||
- [ ] Define explicit non-goals and accepted limitations.
|
- [x] Update project state and dependent plans.
|
||||||
- [ ] Convert the scope into measurable release criteria.
|
|
||||||
- [ ] Update `TASKS.md`, `CODEX.md`, requirements, architecture, and dependent slices.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
## Acceptance Criteria
|
||||||
|
|
||||||
@ -57,10 +55,15 @@ Define one testable MVP release boundary, especially whether IBM Bob/watsonx int
|
|||||||
|
|
||||||
## Progress Log
|
## Progress Log
|
||||||
|
|
||||||
No work recorded yet.
|
### 2026-07-18
|
||||||
|
|
||||||
|
- Removed IBM Bob/watsonx from MVP scope.
|
||||||
|
- Required all five modeled authentication modes.
|
||||||
|
- Approved six end-to-end acceptance workflows.
|
||||||
|
- Created `MVP_SCOPE.md`.
|
||||||
|
|
||||||
## Handoff
|
## Handoff
|
||||||
|
|
||||||
- Last completed: Slice plan created.
|
- Last completed: Product owner approved and documented the MVP scope.
|
||||||
- Next action: Present conflicting statements and obtain product-owner decisions.
|
- Next action: Use `MVP_SCOPE.md` to drive implementation and release acceptance.
|
||||||
- Known blockers: Requires user approval and should be resolved early despite its number.
|
- Known blockers: None.
|
||||||
|
|||||||
5
TASKS.md
5
TASKS.md
@ -117,8 +117,9 @@ This document summarizes the current implementation and the remaining work requi
|
|||||||
|
|
||||||
### MVP scope decision
|
### MVP scope decision
|
||||||
|
|
||||||
- [ ] Decide whether IBM Bob/watsonx integration is required for the initial MVP release or is a post-MVP enhancement.
|
- [x] Decide that IBM Bob/watsonx and other AI integrations are not part of the initial MVP.
|
||||||
- [ ] If AI is required for MVP, implement AI-assisted generation or refinement of canonical project JSON with user review before changes are applied.
|
- [x] Confirm that all five modeled authentication modes are required for MVP.
|
||||||
|
- [x] Define the six end-to-end MVP acceptance workflows in `MVP_SCOPE.md`.
|
||||||
|
|
||||||
### Documentation
|
### Documentation
|
||||||
|
|
||||||
|
|||||||
@ -1,10 +1,13 @@
|
|||||||
import app from './app';
|
|
||||||
import { initDatabase } from './db/init';
|
import { initDatabase } from './db/init';
|
||||||
|
|
||||||
const PORT = process.env.PORT ?? 4000;
|
const PORT = process.env.PORT ?? 4000;
|
||||||
|
|
||||||
initDatabase();
|
initDatabase();
|
||||||
|
|
||||||
|
// Import the app only after the schema exists. Project route modules prepare
|
||||||
|
// their SQL statements during import and therefore require the projects table.
|
||||||
|
void import('./app').then(({ default: app }) => {
|
||||||
app.listen(PORT, () => {
|
app.listen(PORT, () => {
|
||||||
console.log(`Conductor backend listening on port ${PORT}`);
|
console.log(`Conductor backend listening on port ${PORT}`);
|
||||||
});
|
});
|
||||||
|
});
|
||||||
|
|||||||
17
frontend/package-lock.json
generated
17
frontend/package-lock.json
generated
@ -15581,6 +15581,23 @@
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
|
"node_modules/tailwindcss/node_modules/yaml": {
|
||||||
|
"version": "2.9.0",
|
||||||
|
"resolved": "https://registry.npmjs.org/yaml/-/yaml-2.9.0.tgz",
|
||||||
|
"integrity": "sha512-2AvhNX3mb8zd6Zy7INTtSpl1F15HW6Wnqj0srWlkKLcpYl/gMIMJiyuGq2KeI2YFxUPjdlB+3Lc10seMLtL4cA==",
|
||||||
|
"license": "ISC",
|
||||||
|
"optional": true,
|
||||||
|
"peer": true,
|
||||||
|
"bin": {
|
||||||
|
"yaml": "bin.mjs"
|
||||||
|
},
|
||||||
|
"engines": {
|
||||||
|
"node": ">= 14.6"
|
||||||
|
},
|
||||||
|
"funding": {
|
||||||
|
"url": "https://github.com/sponsors/eemeli"
|
||||||
|
}
|
||||||
|
},
|
||||||
"node_modules/tapable": {
|
"node_modules/tapable": {
|
||||||
"version": "2.3.3",
|
"version": "2.3.3",
|
||||||
"resolved": "https://registry.npmjs.org/tapable/-/tapable-2.3.3.tgz",
|
"resolved": "https://registry.npmjs.org/tapable/-/tapable-2.3.3.tgz",
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user