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.
|
||||
- The schema accepts five component types that the editor and runtime cannot render.
|
||||
- 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.
|
||||
|
||||
## Validation Status
|
||||
@ -118,23 +120,24 @@ The initial repository push was completed on 2026-07-18.
|
||||
- Remote `main` contains commit `cce97392f72049007cf00b0aa6c77fb8c8256191`.
|
||||
- The working tree was clean immediately after the push.
|
||||
- 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).
|
||||
- Do not treat the current codebase as freshly validated until dependencies are installed and the validation suite is run.
|
||||
- Node 20/npm 10 clean installs pass after repairing the frontend lockfile.
|
||||
- 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
|
||||
|
||||
Unless the user chooses a different priority, proceed in this order:
|
||||
|
||||
1. Install dependencies using the repository lockfiles and run the existing validation suite.
|
||||
2. Record genuine failures separately from environment/setup failures.
|
||||
3. Implement the five missing MVP GUI components individually, with tests.
|
||||
4. Add visual REST action, event, and binding configuration.
|
||||
5. Add validation to every project save path.
|
||||
6. Implement authentication and secure secret handling.
|
||||
7. Harden the REST proxy and add sanitized execution logging.
|
||||
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.
|
||||
1. Implement the five missing MVP GUI components individually, with tests.
|
||||
2. Add visual REST action, event, and binding configuration.
|
||||
3. Add validation to every project save path.
|
||||
4. Implement authentication and secure secret handling.
|
||||
5. Harden the REST proxy and add sanitized execution logging.
|
||||
6. Add backend, end-to-end, and security regression tests.
|
||||
7. Reconcile and consolidate project documentation.
|
||||
|
||||
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
|
||||
|
||||
Not started
|
||||
In progress
|
||||
|
||||
## Objective
|
||||
|
||||
@ -24,16 +24,16 @@ Produce repeatable automated and manual evidence that the complete MVP builds, r
|
||||
|
||||
## Tasks
|
||||
|
||||
- [ ] Install dependencies from lockfiles and document the supported toolchain.
|
||||
- [ ] Establish clean frontend and backend validation commands.
|
||||
- [x] Install dependencies from lockfiles and document the supported toolchain.
|
||||
- [x] Establish clean frontend and backend validation commands.
|
||||
- [ ] Define release-critical coverage and test layers.
|
||||
- [ ] Complete frontend component, editor, binding, and Preview tests.
|
||||
- [ ] Complete backend CRUD, validation, authentication, proxy, security, and persistence tests.
|
||||
- [ ] Add canonical-document persistence round-trip tests.
|
||||
- [ ] Add workflow-launcher, dependent-dropdown, and dashboard end-to-end scenarios.
|
||||
- [ ] Validate all valid and invalid examples.
|
||||
- [ ] Produce successful frontend and backend production builds.
|
||||
- [ ] Verify full-stack Docker Compose startup, health, restart, and persistence.
|
||||
- [x] Validate all valid and invalid examples.
|
||||
- [x] Produce successful frontend and backend production builds.
|
||||
- [x] Verify full-stack Docker Compose startup, health, restart, and persistence.
|
||||
- [ ] Run the final security regression suite.
|
||||
- [ ] Record commands, test counts, artifacts, limitations, and defects.
|
||||
- [ ] 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
|
||||
|
||||
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
|
||||
|
||||
- Last completed: Slice plan created.
|
||||
- Next action: Install locked dependencies and record the first full baseline.
|
||||
- Known blockers: Final validation depends on Slices 1-5 and the Slice 7 decision.
|
||||
- Last completed: Initial technical and Docker validation baseline.
|
||||
- Next action: Continue release validation as each implementation slice completes.
|
||||
- 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
|
||||
|
||||
Not started
|
||||
Complete
|
||||
|
||||
## Objective
|
||||
|
||||
@ -25,15 +25,13 @@ Define one testable MVP release boundary, especially whether IBM Bob/watsonx int
|
||||
|
||||
## Tasks
|
||||
|
||||
- [ ] Inventory ambiguous or conflicting MVP statements.
|
||||
- [ ] Define minimum release personas and workflows.
|
||||
- [ ] Decide whether AI is required, optional, or post-MVP.
|
||||
- [ ] If required, define the smallest acceptable AI capability and provider boundary.
|
||||
- [ ] Decide whether every modeled authentication type is release-blocking.
|
||||
- [ ] Confirm component, lifecycle, persistence, export, observability, and deployment expectations.
|
||||
- [ ] Define explicit non-goals and accepted limitations.
|
||||
- [ ] Convert the scope into measurable release criteria.
|
||||
- [ ] Update `TASKS.md`, `CODEX.md`, requirements, architecture, and dependent slices.
|
||||
- [x] Inventory ambiguous or conflicting MVP statements.
|
||||
- [x] Define minimum release workflows.
|
||||
- [x] Decide that AI is provider-neutral and post-MVP.
|
||||
- [x] Decide that every modeled authentication type is release-blocking.
|
||||
- [x] Confirm the six acceptance workflows in `MVP_SCOPE.md`.
|
||||
- [x] Convert the decisions into measurable release criteria.
|
||||
- [x] Update project state and dependent plans.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
@ -57,10 +55,15 @@ Define one testable MVP release boundary, especially whether IBM Bob/watsonx int
|
||||
|
||||
## 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
|
||||
|
||||
- Last completed: Slice plan created.
|
||||
- Next action: Present conflicting statements and obtain product-owner decisions.
|
||||
- Known blockers: Requires user approval and should be resolved early despite its number.
|
||||
- Last completed: Product owner approved and documented the MVP scope.
|
||||
- Next action: Use `MVP_SCOPE.md` to drive implementation and release acceptance.
|
||||
- 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
|
||||
|
||||
- [ ] Decide whether IBM Bob/watsonx integration is required for the initial MVP release or is a post-MVP enhancement.
|
||||
- [ ] If AI is required for MVP, implement AI-assisted generation or refinement of canonical project JSON with user review before changes are applied.
|
||||
- [x] Decide that IBM Bob/watsonx and other AI integrations are not part of the initial MVP.
|
||||
- [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
|
||||
|
||||
|
||||
@ -1,10 +1,13 @@
|
||||
import app from './app';
|
||||
import { initDatabase } from './db/init';
|
||||
|
||||
const PORT = process.env.PORT ?? 4000;
|
||||
|
||||
initDatabase();
|
||||
|
||||
app.listen(PORT, () => {
|
||||
// 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, () => {
|
||||
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": {
|
||||
"version": "2.3.3",
|
||||
"resolved": "https://registry.npmjs.org/tapable/-/tapable-2.3.3.tgz",
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user