Skip to main content

Blueprint compatibility

AgentPlane 0.7.10 retires Blueprints from active execution. New tasks, WorkOrders, prompts, state fingerprints, verification inputs, evaluator evidence, and ACR records do not contain a Blueprint selection, snapshot, plan, cursor, or execution state.

The Task Kernel plan and WorkItem graph now own semantic decomposition. The execution contract owns route and authority. Native task obligations own required policy, evidence, lifecycle stages, and stop rules. AgentPlane still requires planning, approval, independent evaluation, deterministic verification, effect-in-doubt handling, and hosted integration where the selected workflow requires them.

Removed active surfaces​

The following interfaces are not available in 0.7.10:

  • the built-in Blueprint registry and resolver;
  • Blueprint graph-plan and execution-state engines;
  • agentplane blueprint ... and agentplane blueprints ... mutation or catalog commands;
  • project-local Blueprint installation, activation, and trust configuration;
  • Blueprint prompt blocks, runner artifacts, generated schemas, and new task fields;
  • Recipe-owned Blueprint extensions as an executable route input.

Do not copy a historical Blueprint into a new task or reconstruct one from prose. Use agentplane task advance <task-id> --agent-json and return the typed PLANNER result. AgentPlane materializes the approved native plan and issues one bounded semantic WorkOrder at a time.

Existing tasks and migration​

Legacy task records do not silently enter the active route. Inspect one record without writing:

agentplane task kernel-migrate <task-id>

The report classifies the source and returns its exact source digest. Apply only after reviewing that report:

agentplane task kernel-migrate <task-id> \
  --apply \
  --source-digest <sha256:digest> \
  --yes

The migration uses an admission fence, preserves the original bytes in a content-addressed backup, writes a migration receipt, and verifies readback. Unknown schemas, ambiguous required inputs, unreconciled effects, active leases, and unsupported backends stop or quarantine the record. They are never converted heuristically.

The emitted proof can roll back the exact migrated bytes while the migrated output, revision, receipt, and backup still match:

agentplane task kernel-migrate <task-id> --rollback <proof.json> --yes

Later task mutations invalidate rollback rather than discarding newer work.

Historical audit boundary​

A small version-labelled decoder remains for historical evidence. It can read a retired task-local Blueprint snapshot to report its digest and audit identity during migration or evidence inspection. It cannot select a route, build a plan, issue a WorkOrder, mutate current task state, or re-enable the retired engine.

Other retained version readers have the same restriction:

  • state-fingerprint v1 is read only for stale-result and historical evidence checks;
  • evaluator work-order v1 and evidence packets remain readable for audit;
  • legacy task fields are removed before current task validation;
  • original bytes, receipts, evidence, and provenance remain preserved.

The executable retirement guards are scripts/checks/no-blueprint-engine.test.mjs, scripts/checks/no-blueprint-cursor.test.mjs, and scripts/checks/blueprint-retirement-map.test.mjs.

Recipe V1 compatibility​

Recipe V1 remains supported for domain guidance, prompt modules, scenarios, templates, tools, and runtime assets. Exact context, output, artifact, evidence, check, and risk requirements are rebound to current Recipe or native task surfaces. A preferred legacy route hint may map only to an exact existing native execution mode.

A custom Blueprint graph has no exact native equivalent. AgentPlane reports that case for manual conversion and does not guess a WorkItem graph. Scenario V2 is not part of 0.7.10.

What did not change​

Blueprint retirement does not remove or weaken these boundaries:

  • PLANNER remains required for new task planning.
  • EVALUATOR remains required wherever current quality policy requires independent review.
  • direct and branch_pr keep their existing repository and provider ownership.
  • User approval and explicit external authority remain separate from plan approval.
  • Verification stays bound to the exact task, native plan, policy, implementation, checks, and observed inputs.
  • Recovery and effect-in-doubt paths remain fail-closed.
  • Lifecycle-owner convergence is deferred; 0.7.10 does not introduce a second coordinator.