flowgraph/tasks/graph-construction-call.md at 466b121f7754e9d7356f5efc2403a9fd07632fae

Files

glm-5.1 466b121f77 decompose architecture into 38 atomic tasks across 12 parallel generations

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.

2026-05-21 20:24:44 +00:00

2.6 KiB

Raw Blame History

id, name, status, depends_on, scope, risk, impact, level

name

status

depends_on

scope

risk

impact

level

graph/construction-call

Implement call graph construction (fromCallEvents, updateFromEvent, addCall, addDependency, updateStatus)

pending

graph/flowgraph-class

schema/enums

broad

high

phase

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

2.6 KiB Raw Blame History