Closes the gap that made the knowledge loop optional/implicit: every non-trivial task now has an EXPLICIT first plan step (research) and last plan step (write back), not just background behavior the model might skip. New MCP tools (the agent had no way to do these before — only REST endpoints existed, unexposed to it): - update_entity_attributes(slug, attributes): shallow-merge new/changed facts into an entity (an IP, a version, a discovered port) so a future task doesn't have to rediscover them from scratch. No approval required — this updates the knowledge graph, not live infra. - create_relationship(source, target, type): record a discovered edge (depends-on, hosts, provides, ...). Idempotent, FK-validated against the ontology's relationship_types, no approval required. SOUL.md: restructured the task loop so step 1 is explicitly "gather knowledge, not just status" (get_entity_knowledge, search_knowledge, get_relations, get_blast_radius, http_get) and the last step before complete_task is explicitly "write back" (update_entity_attributes, create_relationship, upsert_knowledge) — both called out as real plan entries the operator should see in propose_plan, not silent side-work. This is what prevents the graph drifting from reality and is the concrete mechanism behind "tasks compound." propose_plan's tool description reinforces the same first-step/last-step convention at the call site. Verified against the live stack: both tools registered and callable via MCP; update_entity_attributes merged an attribute correctly; create_relationship rejected an invalid type (FK violation, clear error) and succeeded with a valid type+direction, confirmed idempotent (2 calls, 1 row). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
73 KiB
73 KiB