glm-5.1
466b121f77
Decompose the reviewed architecture specs into taskgraph-managed tasks: - 2 setup tasks (project init, test infrastructure) - 4 schema tasks (enums, node attrs, edge attrs, graph schemas) - 1 error hierarchy task - 6 graph tasks (FlowGraph class, 3 construction paths, queries, validation) - 5 analysis tasks (type-compat, build-type-edges, ordering, template-validation, defaults) - 5 component tasks (Operation, Sequential, Parallel, Conditional, Map) - 2 host config tasks (GraphologyHostConfig, ReactiveHostConfig) - 4 reactive tasks (WorkflowRoot, node-status, max-concurrency, retry-semantics) - 3 review tasks (foundation, reactive-and-hosts, complete-library) - 5 meta cluster tasks (schema, graph, component, reactive, analysis layers) - 1 API exports task Validated with taskgraph: zero cycles, 38 tasks, 12 parallel generations. Critical path: 12 tasks through reactive execution layer.
44 lines
2.6 KiB
Markdown
44 lines
2.6 KiB
Markdown
---
|
|
id: graph/construction-call
|
|
name: Implement call graph construction (fromCallEvents, updateFromEvent, addCall, addDependency, updateStatus)
|
|
status: pending
|
|
depends_on:
|
|
- graph/flowgraph-class
|
|
- schema/enums
|
|
scope: broad
|
|
risk: high
|
|
impact: phase
|
|
level: implementation
|
|
---
|
|
|
|
## Description
|
|
|
|
Implement the construction and mutation methods for call graphs: `FlowGraph.fromCallEvents()`, `updateFromEvent()`, `addCall()`, `addDependency()`, `updateStatus()`, `updateCall()`, and `removeCall()`. These handle the dynamic call graph populated from call protocol events.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- [ ] `FlowGraph.fromCallEvents(events: CallEventMapValue[]): CallGraph` — processes events in order, idempotent (duplicate events have no effect)
|
|
- [ ] Event processing: `call.requested` → add node (status: "pending", add triggered edge if parentRequestId), `call.responded` → status: "completed" + output + completedAt, `call.error` → status: "failed" + error + completedAt, `call.aborted` → status: "aborted" + completedAt, `call.completed` → status: "completed" + completedAt
|
|
- [ ] `updateFromEvent(event: CallEventMapValue): void` — single event processing for real-time subscription
|
|
- [ ] `addCall(attrs: CallNodeAttrs): void` — adds call node; if `parentRequestId` present, creates triggered edge from parent to child
|
|
- [ ] `addDependency(source, target): void` — creates depends_on edge with composite key `${source}->${target}:depends_on`
|
|
- [ ] `updateStatus(requestId, status, extra?): void` — validates transition per state machine, throws `InvalidTransitionError` on invalid transition
|
|
- [ ] `updateCall(requestId, attrs): void` — partial merge of call attributes
|
|
- [ ] `removeCall(requestId): void` — removes node and all attached edges
|
|
- [ ] Status transition validation: pending→running→completed/failed, pending→aborted, running→aborted (terminal states: completed, failed, aborted)
|
|
- [ ] Call graph errors are resilient: unknown requestId in responded/error/aborted → log warning, ignore; unknown operationId → create node anyway with status "pending"
|
|
- [ ] Unit tests: fromCallEvents with full event sequences, updateFromEvent real-time pattern, addCall with/without parent, status transitions valid/invalid, addDependency, idempotency
|
|
|
|
## References
|
|
|
|
- docs/architecture/call-graph.md — fromCallEvents, updateFromEvent, status lifecycle, mutations, abort cascading
|
|
- docs/architecture/schema.md — CallEventMapValue mapping to CallNodeAttrs, edge key convention
|
|
- docs/architecture/error-handling.md — call graph error boundary, InvalidTransitionError
|
|
|
|
## Notes
|
|
|
|
> To be filled by implementation agent
|
|
|
|
## Summary
|
|
|
|
> To be filled on completion |