@onlineapps/conn-orch-validator 12.1.1 → 13.0.0

package/src/CookbookTestRunner.js

@@ -4,7 +4,7 @@ const fs = require('fs');
 const path = require('path');
 const crypto = require('crypto');
 const { resolveHeaders } = require('./utils/resolveHeaders');
-const { checkCookbookFormatVersion, readCookbookSteps } = require('./utils/cookbookFormat');
+const { readCookbookSteps } = require('./utils/cookbookFormat');
 const { getTestNamespace, assertWorkspaceId } = require('./utils/testNamespace');
 const {
   describeStepFailure, describeStepIdentity, KIND_STEP, KIND_COOKBOOK_LOAD_FAILURE
@@ -13,6 +13,40 @@ const { parseHandlerRef, resolveHandlerModule } = require('./utils/handlerRef');
 const { createRunContext, resolveStepInput, recordStepOutcome, checkStepInputExpressions }
   = require('./utils/stepReferences');
 const { assertLogger } = require('@onlineapps/logger-contract');
+const { OperationContext } = require('@onlineapps/handler-contract');
+const { validateCookbook: validateCookbookFormat } = require('@onlineapps/cookbook-core');
+const { ErrorClassifier } = require('@onlineapps/error-handler-core');
+
+/**
+ * EPILOGUE OF A RECIPE — the parked `compensate`, woken by owner decision
+ * api/docs/governance/confirmations/meditest-manual-trigger.md 009.
+ *
+ * A recipe may declare `global_error_handler: { strategy: 'compensate',
+ * compensationStep: '<last step>' }`. The runner follows the engine
+ * (`@onlineapps/conn-orch-orchestrator` `WorkflowOrchestrator`, d.934): the
+ * ordinary run never reaches that step; a run that ends unsuccessfully stops at
+ * the failed step and runs the epilogue ONCE, with the failure in scope; a
+ * failed epilogue starts no second one. The SHAPE of the declaration is
+ * `@onlineapps/cookbook-core`'s (`validateCookbook`, which
+ * `CookbookTestRunner.validateCookbook` runs first); the runner reads
+ * `compensationStep` and nothing else.
+ *
+ * Where the failure sits in scope — the root and key the engine writes it to,
+ * `{{global_error_handler._failure.<field>}}`.
+ */
+const EPILOGUE_FAILURE_ROOT = 'global_error_handler';
+const EPILOGUE_FAILURE_KEY = '_failure';
+
+/**
+ * The handler's own thrown error behind a step result, kept out of the report.
+ *
+ * The step record carries `error.code` as `code || name` — a label for the
+ * reader of the log. The epilogue's `_failure.error_code` must be what the
+ * engine puts there, the thrown `code` or `null`, and `details` likewise; so
+ * the raw values are held here, beside the record rather than in it, and the
+ * report's shape does not change.
+ */
+const THROWN_ERRORS = new WeakMap();
 
 /**
  * The step's stopwatch, spelled out. A single total hid the fact that
@@ -92,19 +126,60 @@ function resolveOutputField(container, fieldPath) {
  * module via `require()` and calls `handler(input, ctx)` directly in-process
  * (no HTTP). Operations without a `handler` field are an explicit error.
  *
- * The handler dispatch builds a minimal real ctx:
- *   { logger, tenant_id, workspace_id, correlation_id, db: null, cache: null,
- *     httpClient: null, secrets: null, state: null, stream: null,
- *     abortSignal: null }
- * matching the shape ServiceWrapper.ContextBuilder produces in production
- * (see api/docs/biz/10-invocation/handler-dispatch.md). Handlers
- * that need DB access import sequelize directly from their own
- * src/config/database.js module (see biz/60-templates/onboarding-checklist.md §9a);
- * connector slots stay null and the handler surfaces its own failure if
- * something it genuinely needs is missing.
+ * The handler dispatch builds a minimal real ctx: an instance of the same
+ * `OperationContext` class production hands a handler, imported from
+ * `@onlineapps/handler-contract` (never from the wrapper, which sits a layer
+ * above — architecture-principles.md §7; conf handler-contract 001). So the
+ * frozen instance and its prototype helpers are the class's, not a mirror of
+ * them. Its shape is NOT written out here, meaning which slots the instance
+ * is filled with. A second enumeration is a copy, and a copy drifts silently
+ * (`.claude/rules/doc-code-binding.md` §2): this one named eleven slots while
+ * `_dispatchViaHandler` below built seventeen. Three places hold the slot set,
+ * and each of them is checked — the fields passed to the constructor in
+ * `_dispatchViaHandler`, the slot set asserted by value in
+ * tests/unit/CookbookTestRunner.ctxShape.test.js, and the contract node
+ * api/docs/biz/40-cookbooks/test-runner-flow.md.
+ *
+ * Connector slots stay null and the handler surfaces its own failure if
+ * something it genuinely needs is missing; a handler that needs DB access
+ * imports sequelize directly from its own src/config/database.js module
+ * (see api/docs/biz/60-templates/onboarding-checklist.md §9a).
  *
  * Supports unified cookbook format for both testing (with expect) and production (without expect).
  */
+/**
+ * The recipe's epilogue step id, or `null` when it declares none.
+ *
+ * Only `compensationStep` is read: the declaration was validated by
+ * `@onlineapps/cookbook-core` before this runs.
+ *
+ * @param {Object} cookbook
+ * @returns {string|null}
+ */
+function declaredEpilogueStepId(cookbook) {
+  const handler = cookbook[EPILOGUE_FAILURE_ROOT];
+  return handler && typeof handler === 'object' && typeof handler.compensationStep === 'string'
+    ? handler.compensationStep
+    : null;
+}
+
+/**
+ * What the report says about a failed epilogue: the handler's own `{ code,
+ * message }` when it threw, otherwise the reason the step record gives.
+ *
+ * @param {Object} result - the epilogue's step result
+ * @returns {{code?: string, message: string}}
+ */
+function describeEpilogueError(result) {
+  if (result.error && typeof result.error === 'object') {
+    return { code: result.error.code, message: result.error.message };
+  }
+  if (typeof result.error === 'string') {
+    return { message: result.error };
+  }
+  return { message: result.validationErrors.join('; ') };
+}
+
 class CookbookTestRunner {
   constructor(options = {}) {
     if (!options.serviceName) {
@@ -115,7 +190,7 @@ class CookbookTestRunner {
     // calls info() and error() throughout a run. A logger without them therefore
     // constructed fine and died on the first log line: delayed validation, which
     // architecture-principles.md §4 forbids. Owner confirmation:
-    // docs/governance/confirmations/connector-logger-contract.md 001.
+    // api/docs/governance/confirmations/connector-logger-contract.md 001.
     assertLogger('CookbookTestRunner', options.logger, 'the runner writes where the service writes');
 
     // A RETIRED option is refused, never ignored: a caller that still writes it
@@ -142,6 +217,12 @@ class CookbookTestRunner {
       this._servicePathByName.set(this.serviceName, this.servicePath);
     }
 
+    // The engine's classifier, not a copy of it: the engine asks the injected
+    // `@onlineapps/conn-infra-error-handler` (`classifyError`), which delegates
+    // to this class of `@onlineapps/error-handler-core`. Stateless — one per
+    // runner. Read by `_runEpilogue` for `_failure.error_type`.
+    this.errorClassifier = new ErrorClassifier();
+
     // Test results
     this.results = this._emptyResults();
   }
@@ -171,12 +252,13 @@ class CookbookTestRunner {
     try {
       this.validateCookbook(cookbookData);
 
-      // What the recipe WRITES, before anything of it runs. A helper call and a
-      // `{{steps.<id>}}` naming no step of this cookbook are both refused here:
-      // production evaluates the first and refuses the second at submission, so
-      // letting either through as literal text would make a green Tier-1 say
-      // more than production will (utils/stepReferences.js). The step values
-      // themselves are resolved per step, later and against what ran.
+      // What the recipe WRITES, before anything of it runs, that only Tier-1
+      // must refuse: a helper call. Production evaluates it, this runner has no
+      // helper registry, so letting it through as literal text would make a
+      // green Tier-1 say more than production will (utils/stepReferences.js).
+      // A `{{steps.<id>}}` naming no step is cookbook-core's refusal, above.
+      // The step values themselves are resolved per step, later and against
+      // what ran.
       const referenceProblem = await checkStepInputExpressions(readCookbookSteps(cookbookData.steps));
       if (referenceProblem !== null) {
         throw new Error(`[CookbookTestRunner] ${referenceProblem}`);
@@ -198,11 +280,21 @@ class CookbookTestRunner {
     this.logger.info(`Mode: ${testConfig.mode || 'production'}, Test: ${isTestMode}`);
 
     // Already proved to be the array shape by validateCookbook above.
-    const stepsArray = readCookbookSteps(cookbookData.steps);
+    const allSteps = readCookbookSteps(cookbookData.steps);
+
+    // The epilogue step, when the recipe declares one. cookbook-core has proved
+    // it is the LAST top-level step, so the ordinary run is every step before
+    // it — the runner's form of the engine's `nextStep === compensationStep`
+    // stop.
+    const epilogueStepId = declaredEpilogueStepId(cookbookData);
+    const stepsArray = epilogueStepId === null
+      ? allSteps
+      : allSteps.filter((step) => step.step_id !== epilogueStepId);
 
     // Execute steps
     const cookbookName = cookbookData.description || 'Unnamed';
     const stepResults = [];
+    let failedStep = null;
     // What the steps of THIS cookbook have produced so far — the scope a
     // `{{steps.<step_id>.output.…}}` reference resolves against
     // (src/utils/stepReferences.js). It is built here, per cookbook, because
@@ -222,6 +314,14 @@ class CookbookTestRunner {
       stepResult.cookbook = cookbookName;
       stepResults.push(stepResult);
 
+      // A recipe with an epilogue ends at its first failed step, as the engine
+      // ends the run there; the epilogue then answers that failure. Without the
+      // declaration nothing changes: only a failed step WITH expect stops the run.
+      if (!stepResult.passed && epilogueStepId !== null) {
+        failedStep = { step, result: stepResult };
+        break;
+      }
+
       // If step failed and has expect, fail immediately
       if (!stepResult.passed && step.expect) {
         break;
@@ -243,6 +343,19 @@ class CookbookTestRunner {
       steps: stepResults
     };
 
+    // The epilogue is reported beside the steps, never among them: it is not a
+    // step of the ordinary run, so it moves none of the counts above.
+    if (failedStep !== null) {
+      results.epilogue = await this._runEpilogue({
+        epilogueStep: allSteps.find((step) => step.step_id === epilogueStepId),
+        failedStep,
+        cookbookData,
+        testConfig,
+        runContext,
+        stepIndex: allSteps.length - 1
+      });
+    }
+
     // Update aggregate results
     this.results.total += results.total;
     this.results.passed += results.passedCount;
@@ -257,6 +370,58 @@ class CookbookTestRunner {
     return results;
   }
 
+  /**
+   * Run the recipe's epilogue once, after the step that ended the run failed.
+   *
+   * The failure goes into scope under `global_error_handler._failure` with all
+   * six keys of the engine's record (`@onlineapps/cookbook-core` `RunFailure`),
+   * `null` where the runner has no value — never an invented one:
+   *   - `error_type` is what the engine's classifier answers for the thrown
+   *     error (`@onlineapps/error-handler-core` `ErrorClassifier.classify`, the
+   *     core behind the engine's `errorHandler.classifyError`) — always a
+   *     string, as `RunFailure` requires;
+   *   - `error_code` and `details` are the thrown error's own, or `null`.
+   *
+   * A step whose handler succeeded but whose `expect` was not met threw
+   * nothing. Tier-1 `expect` has no counterpart in the engine, so there is no
+   * engine record to mirror: `error_code` and `details` are `null`, and
+   * `error_type` is the classifier's answer for no error (`classify(null)`,
+   * `UNKNOWN`) — asked, not written here.
+   *
+   * @private
+   * @returns {Promise<{step_id: string, status: 'passed'|'failed', output?: *, error?: Object}>}
+   */
+  async _runEpilogue({ epilogueStep, failedStep, cookbookData, testConfig, runContext, stepIndex }) {
+    const thrown = THROWN_ERRORS.get(failedStep.result);
+    const failure = {
+      step_id: failedStep.step.step_id,
+      service: failedStep.step.service,
+      operation: typeof failedStep.step.operation === 'string' ? failedStep.step.operation : null,
+      error_type: this.errorClassifier.classify(thrown === undefined ? null : thrown),
+      error_code: thrown && thrown.code !== undefined && thrown.code !== null ? thrown.code : null,
+      details: thrown && thrown.details !== undefined && thrown.details !== null ? thrown.details : null
+    };
+
+    const epilogueContext = {
+      ...runContext,
+      [EPILOGUE_FAILURE_ROOT]: { ...cookbookData[EPILOGUE_FAILURE_ROOT], [EPILOGUE_FAILURE_KEY]: failure }
+    };
+
+    const result = await this.executeStep(epilogueStep, testConfig, stepIndex, cookbookData.defaults, epilogueContext);
+
+    if (result.passed) {
+      this.logger.info(`[CookbookTestRunner] Run ended unsuccessfully at step '${failure.step_id}'; `
+        + `epilogue step '${epilogueStep.step_id}' after step '${failure.step_id}' PASSED`);
+      return { step_id: epilogueStep.step_id, status: 'passed', output: result.actual };
+    }
+
+    const error = describeEpilogueError(result);
+    this.logger.error(`[CookbookTestRunner] Run ended unsuccessfully at step '${failure.step_id}', and `
+      + `epilogue step '${epilogueStep.step_id}' after step '${failure.step_id}' FAILED too — ${error.message}. `
+      + 'No second epilogue runs.');
+    return { step_id: epilogueStep.step_id, status: 'failed', error };
+  }
+
   /**
    * Run all cookbooks in a directory — or the ones running one operation.
    *
@@ -447,8 +612,15 @@ class CookbookTestRunner {
       passed: false,
       // Three separate numbers, because they answer different questions.
       // `duration` is the wall clock of the whole step. `setupDurationMs` is
-      // what the RUNNER spent getting to the handler — reading operations.json
-      // and require()ing the module, a one-off cost per process. Only
+      // what the RUNNER spent getting to the handler, and that is two costs of
+      // different shape: `resolveOperation()` below re-reads
+      // `config/service/operations.json` from disk on EVERY step (measured:
+      // five steps, five reads), while `require()` of the handler module is
+      // served from Node's module registry after the first step that asks for
+      // it. Only the second one is a one-off per process — until d.795b this
+      // comment said both were, which made the per-step read invisible to
+      // anybody reading the number. This is the Tier-1 runner at boot, so the
+      // repeated read is per cookbook step, never on a request path. Only
       // `handlerDurationMs` is the handler's own runtime, and only that one is
       // what `expect.duration.max` asserts about (see validateExpectations).
       duration: 0,
@@ -467,8 +639,8 @@ class CookbookTestRunner {
       // The namespace is a safety boundary, so it is resolved before anything
       // else happens — before the operation is even looked up. utils/testNamespace
       // is the single owner of that decision: it reads the TESTING_* env contract
-      // (docs/biz/40-cookbooks/test-env-vars.md +
-      // docs/biz/60-templates/env-conventions.md — the TESTING_ prefix marks
+      // (api/docs/biz/40-cookbooks/test-env-vars.md +
+      // api/docs/biz/60-templates/env-conventions.md — the TESTING_ prefix marks
       // values that legitimately ship to production, because this runner fires at
       // every service startup, prod included) AND it returns a namespace only for
       // the non-production environment classes — 96 CI, 97 TESTING, 98 DEVEL,
@@ -599,22 +771,62 @@ class CookbookTestRunner {
     return envWorkspaceId;
   }
 
+  /**
+   * The per-step limit, read from the ONE place a recipe may set it.
+   *
+   * The cookbook's `test.timeout` overrides the runner default
+   * (`api/docs/biz/40-cookbooks/testing.md` § The `test` block): absent means the
+   * constructor's `timeout`, which the constructor has already proved positive.
+   * Present, it must be a positive finite number of milliseconds and is refused
+   * by name otherwise. Until d.1001 this was `testConfig.timeout || this.timeout`,
+   * which turned a written `0`, `-1` or `NaN` silently into the runner default and
+   * raced the handler against a string `"5"` (`architecture-principles.md` §3).
+   *
+   * @param {Object} testConfig - the cookbook's `test` block
+   * @returns {number} milliseconds
+   */
+  _stepTimeout(testConfig) {
+    if (testConfig.timeout === undefined) {
+      return this.timeout;
+    }
+    const { timeout } = testConfig;
+    if (typeof timeout !== 'number' || !Number.isFinite(timeout) || timeout <= 0) {
+      const shown = typeof timeout === 'string' ? JSON.stringify(timeout) : String(timeout);
+      throw new Error(
+        `[CookbookTestRunner] test.timeout must be a positive number of milliseconds - got ${shown}. `
+          + 'Expected: the per-step limit the recipe sets over the runner default, or no test.timeout '
+          + 'at all to keep that default. '
+          + 'Fix: write a positive number (e.g. "timeout": 5000) in the cookbook\'s test block, or drop the key.'
+      );
+    }
+    return timeout;
+  }
+
   /**
    * Handler dispatch: require handler module, build minimal real ctx, call
-   * handler(input, ctx). Mirrors the production ContextBuilder shape
-   * (see api/docs/biz/10-invocation/handler-dispatch.md) with
-   * all connector slots set to null — handlers that need DB access use
-   * direct sequelize import per biz/60-templates/onboarding-checklist.md §9a.
+   * handler(input, ctx). The fields passed to `new OperationContext(...)` below
+   * are the one statement of the runner's slot set — see api/docs/biz/40-cookbooks/test-runner-flow.md and
+   * api/docs/biz/10-invocation/operation-context.md. All connector slots are
+   * null; handlers that need DB access use a direct sequelize import per
+   * api/docs/biz/60-templates/onboarding-checklist.md §9a.
    */
   async _dispatchViaHandler({ step, input, spec, testConfig, validationTenantId, validationWorkspaceId, result, startTime }) {
-    const stepTimeout = testConfig.timeout || this.timeout;
-    const correlationId = step.correlation_id || crypto.randomUUID();
-    // Production ctx (from ContextBuilder) always carries workflow_id + person_id.
-    // Handlers check both — mirror them here (person_id nullable per envelope).
-    const workflowId = step.workflow_id || correlationId;
+    const stepTimeout = this._stepTimeout(testConfig);
+    // The run's identity is the RUNNER's to make, never the step's (d.1001). The
+    // step format (`api/docs/biz/40-cookbooks/format.md` § Task step, cookbook-core's
+    // `TaskStep`) declares neither `correlation_id` nor `workflow_id`, and nothing
+    // in production reads them off a step — so a step that still writes them is
+    // treated like any other undeclared key: not refused (`TaskStep` keeps
+    // `additionalProperties: true`, conf `parked-features` 001), and not read.
+    // Production ctx (from ContextBuilder) always carries workflow_id; one step
+    // here is one run, so the workflow is named by the step's own correlation id.
+    const correlationId = crypto.randomUUID();
+    const workflowId = correlationId;
+    // `person_id` is still read off the step — whether the runner carries an
+    // acting person, and from where, is conf `testing-tenant-identity` 001.
     const personId = step.person_id != null ? step.person_id : null;
 
-    const ctx = {
+    const ctx = new OperationContext({
       logger: this.logger,
       tenant_id: validationTenantId,
       workspace_id: validationWorkspaceId,
@@ -623,8 +835,7 @@ class CookbookTestRunner {
       person_id: personId,
       operation_name: step.operation,
       // WHICH STEP is running, not merely which operation. Production
-      // `OperationContext` carries it among its 16 fields
-      // (`@onlineapps/service-wrapper` src/OperationContext.js), and a handler
+      // `OperationContext` carries it among its fields, and a handler
       // that stores a file cannot do without it:
       // `@onlineapps/conn-orch-content-resolver` keys every stored object on
       // `content/<workflow_id>/<step_id>` and refuses to invent either half.
@@ -655,7 +866,7 @@ class CookbookTestRunner {
         'x-workspace-id': String(validationWorkspaceId),
         ...resolveHeaders(step.headers)
       }
-    };
+    });
 
     const request = {
       mode: 'handler',
@@ -692,7 +903,11 @@ class CookbookTestRunner {
 
     // Everything up to here was the runner getting ready: the namespace, the
     // operations.json read, require.resolve and the require() of the handler
-    // module. That is a one-off cost per process and it is not the handler's.
+    // module. None of it is the handler's own time — and only the module load
+    // is a one-off per process (Node's module registry serves it after the
+    // first step). The operations.json read happens on EVERY step, because
+    // `resolveOperation()` opens the file each time it is called; the same
+    // sentence one screen up said otherwise until d.795b/d.795c.
     const handlerStart = Date.now();
     result.setupDurationMs = handlerStart - startTime;
 
@@ -705,6 +920,7 @@ class CookbookTestRunner {
       ]);
     } catch (error) {
       handlerError = error;
+      THROWN_ERRORS.set(result, error);
     } finally {
       clearTimeout(timeoutId);
     }
@@ -1091,34 +1307,32 @@ class CookbookTestRunner {
   }
 
   /**
-   * Validate cookbook format
+   * Validate cookbook format — ONE owner, then what only the runner knows.
    *
-   * `steps` is an ARRAY of step objects — the only shape the format allows
-   * (owner confirmation `cookbook-steps-shape` 001 of 2026-09-05). The runner
-   * used to accept an object keyed by `step_id` and convert it, which made this
-   * gate pass cookbooks the production WorkflowOrchestrator threw on. The shape
-   * rule itself lives in `utils/cookbookFormat.readCookbookSteps`, the same
-   * owner `CookbookTestUtils.validateCookbook` reads, so the two entry points
-   * cannot disagree about what a cookbook's steps are.
+   * FIRST, `@onlineapps/cookbook-core` `validateCookbook`: the same function the
+   * receiving side throws on
+   * (api/docs/governance/confirmations/cookbook-validation-placement.md 001).
+   * It refuses a non-object, a missing or pre-2.1 `version`, a missing, empty
+   * or non-array `steps` (the array is the only shape — owner confirmation
+   * `cookbook-steps-shape` 001), a step without `step_id`/`type`/`service`/
+   * `operation`, a step carrying `id` (d.983; the runner's own copy of that ban
+   * went with d.985), a duplicate `step_id`, a `{{steps.<id>}}` or `depends_on`
+   * naming no step, a positional step reference, a non-integer `workspace_id`,
+   * and the epilogue rules (d.933, d.942). Until d.980 the runner held its own
+   * copy of most of these, with its own messages, ahead of this call — one
+   * concern on two rails (`.claude/rules/change-discipline.md` § One rail per
+   * concern). The words a biz service reads in its Tier-1 output for these
+   * cases are cookbook-core's.
    *
-   * The format-version check is FIRST and unconditional. Until 2026-08-27 it
-   * lived only in `CookbookTestUtils.validateCookbook`, reachable exclusively
-   * through the optional `tests/bootstrap/service-readiness.test.js` wrapper
-   * that 3 of 8 biz repos happen to have — so the rule from
-   * api/docs/biz/40-cookbooks/format.md § "Required fields" was, in practice,
-   * opt-in per repo, and 4 repos ship cookbooks with no `version` field at all.
-   * A check a repo can decline is not a check (automation-gates §1.5).
+   * THEN, what cookbook-core accepts and the runner must not:
+   * `test.mockInfrastructure` — the retired option, refused by name.
+   *
+   * @param {*} cookbook - the parsed cookbook
+   * @returns {true}
+   * @throws {Error} the first refusal, in the words of its owner
    */
   validateCookbook(cookbook) {
-    if (!cookbook || typeof cookbook !== 'object' || Array.isArray(cookbook)) {
-      throw new Error('[CookbookTestRunner] Cookbook is not a JSON object - Expected an object with "version" and "steps". '
-        + 'Fix: check the cookbook file content (api/docs/biz/40-cookbooks/format.md § Basic structure).');
-    }
-
-    const versionProblem = checkCookbookFormatVersion(cookbook.version);
-    if (versionProblem) {
-      throw new Error(`[CookbookTestRunner] ${versionProblem}`);
-    }
+    validateCookbookFormat(cookbook);
 
     // The retired option, in the other place a caller could still write it. The
     // cookbook schema admits additional properties inside `test`, so nothing
@@ -1136,50 +1350,6 @@ class CookbookTestRunner {
         + '(api/docs/biz/40-cookbooks/format.md § Optional top-level fields).');
     }
 
-    if (cookbook.steps === undefined || cookbook.steps === null) {
-      throw new Error('[CookbookTestRunner] Cookbook has no steps - Expected "steps": [ … ] with at '
-        + 'least one step object carrying "step_id". '
-        + 'Fix: add the steps array (api/docs/biz/40-cookbooks/format.md § Required fields).');
-    }
-
-    // Throws unless `steps` is the array the format requires.
-    const stepsArray = readCookbookSteps(cookbook.steps);
-
-    if (stepsArray.length === 0) {
-      throw new Error('[CookbookTestRunner] Cookbook must have at least one step - Expected a non-empty '
-        + 'steps array. Fix: add at least one step (api/docs/biz/40-cookbooks/format.md § Required fields).');
-    }
-
-    // The three fields `@onlineapps/cookbook-core` 5.0.0 requires of a task step
-    // beyond `type` (`schemas/cookbook.v2.schema.json`
-    // definitions.TaskStep.required). `step_id` comes FIRST, because it is what
-    // the other two messages name the step by: until d.516b this guard checked
-    // only the last two and wrote `Step ${step.step_id || 'unknown'}`, so a
-    // cookbook missing the field the whole format addresses steps by was
-    // accepted here and its diagnostics said `Step unknown`. A stand-in name is
-    // the fallback `.claude/rules/architecture-principles.md` §3 forbids; with
-    // the field required, the case it stood in for cannot occur.
-    stepsArray.forEach((step, index) => {
-      const position = index + 1;
-      if (typeof step.step_id !== 'string' || step.step_id.length === 0) {
-        throw new Error(`[CookbookTestRunner] Step #${position} has no step_id - every step of a v2.1 `
-          + 'cookbook is addressed by its own step_id (@onlineapps/cookbook-core '
-          + 'schemas/cookbook.v2.schema.json definitions.TaskStep.required). '
-          + `Fix: add "step_id" to step #${position} `
-          + '(api/docs/biz/40-cookbooks/format.md § Required fields).');
-      }
-      if (!step.service) {
-        throw new Error(`[CookbookTestRunner] Step ${step.step_id} must have service - `
-          + 'Expected the name of the service that runs the step. Fix: add "service" to that step '
-          + '(api/docs/biz/40-cookbooks/format.md § Step definition).');
-      }
-      if (!step.operation) {
-        throw new Error(`[CookbookTestRunner] Step ${step.step_id} must have operation - `
-          + 'Expected the operation that service exposes. Fix: add "operation" to that step '
-          + '(api/docs/biz/40-cookbooks/format.md § Step definition).');
-      }
-    });
-
     return true;
   }