/** * Turn the dependencies a model described into the step ids a plan uses. * * The model is shown `depends_on: string[]` on every plan step, described to * it as "Step descriptions this depends on" — descriptions, because that is * the only handle it has. Step ids are minted at execute time (`step_1`, * `step_2`, ...), so the model cannot name one and should not be asked to. * * The translation between the two was never written. `approve_plan` passed * `dependsOn: []` for every step, so whatever ordering the model declared * was dropped at the one place it entered the system. The visible cost is * not scheduling — `PlanManager.getNextPendingStep` holds the dependency * gate and currently has no callers — it is the APPROVAL: `dependsOn` is * serialized into the `plan_approval` payload a human reads before saying * yes, so a reviewer was shown a plan whose steps all looked independent * however carefully the model had ordered them. */ /** What the model said, before ids exist. */ export interface DescribedStep { readonly description: string; readonly depends_on?: readonly string[]; } export type ResolvedDependencies = { readonly ok: true; readonly dependsOn: readonly (readonly string[])[]; } | { readonly ok: false; readonly error: string; }; /** * Resolve every step's declared dependencies to step ids, or refuse. * * Returns one id array per input step, positionally. * * **Refusing beats dropping.** Every failure here means the model expressed * an ordering it cannot have and the plan does not mean what it says; the * old behaviour — discard silently — is what put an empty dependency list in * front of a human approver. The error text names the offending description * so the model can correct it and call again, which is the same shape every * other recoverable tool failure in this kernel uses. */ export declare function resolvePlanDependencies(steps: readonly DescribedStep[], idOf: (index: number) => string): ResolvedDependencies; //# sourceMappingURL=plan-dependencies.d.ts.map