@mstar-harness/engine 3.9.3 → 3.10.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/audit.d.ts CHANGED
@@ -1,4 +1,5 @@
1
1
  import type { GateResult } from "./core.js";
2
+ import { type WorkflowDeliveryKind } from "./workflow.js";
2
3
  /** Priority values (mstar-audit SKILL.md § Plan output (all variants) Status block). */
3
4
  export declare const AUDIT_PRIORITIES: readonly ["P1", "P2", "P3"];
4
5
  export type AuditPriority = (typeof AUDIT_PRIORITIES)[number];
@@ -226,6 +227,20 @@ export type PromoteAuditPlansOptions = {
226
227
  harnessDir: string;
227
228
  /** Default: basename of `outDir` (e.g. `audit-2026-08-22`). */
228
229
  workflowId?: string;
230
+ /**
231
+ * Delivery kind declared for the promoted plans (contract §1/§4a). Required —
232
+ * the promoted lifecycle is a `type: plan` workflow, so its delivery kind is
233
+ * declared at registration, never inferred and never defaulted in code (an
234
+ * audit promotion that left it unset minted an active snapshot no close path
235
+ * could complete).
236
+ */
237
+ deliveryKind: WorkflowDeliveryKind;
238
+ /** Delivery source branch, recorded as `branch.source`. Required for `development`. */
239
+ branchSource?: string;
240
+ /** Delivery target branch, recorded as `branch.target`. Required for `development`. */
241
+ branchTarget?: string;
242
+ /** Completion policy for `verification/report-only` promotions. Required for that kind. */
243
+ completionPolicy?: string;
229
244
  };
230
245
  /**
231
246
  * Promote selected audit plans into the v2 workflow lifecycle as a
@@ -246,16 +261,17 @@ export type PromoteAuditPlansOptions = {
246
261
  * same root lock `registerWorkflow` uses — so the guard is check-then-act
247
262
  * safe: two concurrent same-id promotes cannot both pass it (one writes
248
263
  * and registers; the other re-checks under the lock and refuses). The
249
- * snapshot is written directly with `writeJson` under the root lock (never
250
- * a nested `writeWorkflowSnapshot` its own snapshot-dir lock would be a
251
- * second serialization point; the root lock must be THE serialization
252
- * point). The root upsert replicates `registerWorkflow` semantics inline
264
+ * snapshot is written create-only through the routed
265
+ * `writeWorkflowSnapshot(snapshot, dir, { createOnly: true })`, whose own
266
+ * snapshot-dir lock nests inside the root lock (root snapshot is the
267
+ * documented acquisition order). The root upsert replicates
268
+ * `registerWorkflow` semantics inline
253
269
  * via the shared `registerWorkflowEntryLocked` helper (calling
254
270
  * `registerWorkflow` itself would re-enter the non-reentrant root lock).
255
271
  *
256
- * On any failure inside the lock, the partial snapshot + now-empty
257
- * workflow dir are rolled back so a retry converges after the root
258
- * conflict is resolved.
272
+ * On any failure inside the lock, the snapshot this call created (and only
273
+ * that exact byte version) plus the now-empty workflow dir are rolled back so
274
+ * a retry converges after the root conflict is resolved.
259
275
  */
260
276
  export declare function promoteAuditPlans(outDir: string, selected: readonly string[], options: PromoteAuditPlansOptions): Promise<{
261
277
  workflowId: string;