Repository navigation
Planner sees the capability catalog and names each task's capabilities (#49) - #88
Merged
Merged
Conversation
TaskDefinition gains optional id, depends_on and needs; ExecutionPlan gains from_hash and validate! (duplicate ids, dangling references, self-dependency, cycles). All additive: flat plans serialize and load unchanged. First of three staged PRs for #20. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
TaskPlanner's structured-output schema now asks for a plan-local id,
a depends_on list and needs wiring on every task, and the prompt tells
the model what each is for. needs travels as {name, task} pairs since
strict schemas cannot describe a free-form object; the parser folds
them into the hash TaskDefinition stores. Malformed edges are dropped
with a warning. After parsing, the plan is run through
ExecutionPlan#validate! and any dangling reference or cycle is logged,
with the edges kept so the plan stays inspectable and editable.
Part 2 of 3 for #20 (stacked on #35).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
#49) When TaskPlanner is given a registry, the user message ends with a "Capabilities available" block (name: description, latest version of each) and the task schema gains a required `capabilities` string array. Names the LLM emits that are not in the catalog are dropped with a warning, as #37 does for malformed edges. Without a registry the prompt and schema are byte-identical to before. TaskDefinition carries `capabilities` (default [], serialized only when non-empty so flat plans round-trip unchanged), hands it to the Task it builds, and Task.from_definition does the same. AgentAssemblyEngine seeds requirements from task.capabilities at importance 1.0 before the description/agent-spec/input inference runs, so assembly honors the plan's choice and infers only to fill gaps. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Resolve against #40: TaskDefinition carries both capabilities and on_failure; the planner schema keeps on_failure and adds capabilities only when a registry is given; the catalog prompt becomes step 8.
# Conflicts: # CHANGELOG.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Integrates #53 by @minerva-sky, whose branch could not be updated in place (fork push not available from this session). The original commits are preserved on this branch.
Merged current main and resolved real conflicts with #40:
TaskDefinitioncarries bothcapabilitiesandon_failure; the planner schema keepson_failureand addscapabilitiesonly when a registry is given; the catalog prompt step is renumbered 7 → 8. Added a CHANGELOG entry (the original only inherited the #35/#37 stack entries).Closes #49. Original: #53.