resolve all remaining open questions (OQ-03–OQ-29), add ADR-006

Resolve all 19 remaining open questions across the architecture. Every
question now has a documented resolution with rationale:

- OQ-004/OQ-029: edgeType is a universal required attribute on all edges,
  single graph per FlowGraph instance (ADR-006)
- OQ-011: No OR preconditions for v1; preconditionMode as v2 extension
- OQ-012: maxConcurrency enforced via reactive counting semaphore
- OQ-014: Unknown operationId creates node with pending status
- OQ-017: Expose common graphology traversal methods on FlowGraph (80/20)
- OQ-020: condition as Type.Unknown() with string/function documentation
- OQ-022: Identity imported from @alkdev/operations peer dep
- All other questions resolved with documented rationale

Fix three critical issues found by architecture review:
1. edgeType serialization/validation gap: document two-step validation
2. CallEdgeAttrs runtime discrimination: edgeType as runtime discriminant,
   depends_on edges clarified as observability-only (not execution)
3. ADR-005 signal mutation inconsistency: explicitly distinguish call-level
   statuses (event-log-driven) from workflow-derived statuses (signal-mutation)

Additional clarifications:
- dataFlow inference uses conservative strategy (defaults false)
- Conditional.test string resolution: operationName → status === completed
- Add negated field to TemplateEdgeAttrs for else-branch conditions
- Document edge key priority convention for composite keys
- Add maxConcurrency semaphore design to reactive-execution.md

docs/architecture/analysis.md

@@ -1,6 +1,6 @@
 ---
 status: draft
-last_updated: 2026-05-20
+last_updated: 2026-05-22
 ---
 
 # Analysis Functions
@@ -330,13 +330,13 @@ These are in-memory operations with no I/O. The dominant cost is `buildTypeEdges
 
 ## Open Questions
 
-1. **How deep should `typeCompat` check?** Currently it checks top-level field existence and type compatibility. Should it recursively check nested objects and arrays? Full recursive checking is more thorough but slower and may produce false negatives for schemas with dynamic structures.
+1. ~~**How deep should `typeCompat` check?**~~ **Resolved (OQ-002/ADR-005)**: Type compatibility checking performs deep recursive structural comparison. The `TypeCompatResult` includes `mismatches?: TypeMismatch[]` with field-level diagnostics for incompatible edges. Type checking only applies to state-transfer edges (where `dataFlow: true` on `TemplateEdgeAttrs`). Temporal-only edges bypass type checking entirely. Remaining detail decisions (recursive depth limits, unknown/union type handling) are implementation concerns, not architecture decisions.
 
-2. **Should `validateTemplate` check runtime preconditions?** Currently it only checks structural validity and type compatibility. Runtime preconditions (e.g., "operation B requires an API key that operation A doesn't have access to") are beyond the scope of static analysis and belong to the access control layer.
+2. ~~**Should `validateTemplate` check runtime preconditions?**~~ **Resolved (OQ-027)**: Explicitly out of scope. `validateTemplate` only checks structural validity and type compatibility. Runtime preconditions (e.g., "operation B requires an API key that operation A doesn't have access to") belong to the access control layer, not the static analysis layer. This is a deliberate scope boundary, not a design gap.
 
-3. **Should analysis functions be async?** For very large graphs (thousands of nodes), type compatibility checking could be slow. Making it async would allow incremental progress reporting. Current graphs are small enough (50-200 nodes) that synchronous checking is fine.
+3. ~~**Should analysis functions be async?**~~ **Resolved (OQ-024)**: No — synchronous is sufficient for current scale. Expected graph sizes (10-200 nodes) are well within synchronous processing limits. Making functions async would add API complexity (Promise return types, async/await boilerplate) for no current benefit. If large graphs become common, async variants can be added alongside the synchronous ones.
 
-4. **Should `parallelGroups` account for resource constraints?** Currently it returns the theoretical maximum parallelism. An optional `maxConcurrency` parameter could limit group sizes for realistic scheduling.
+4. ~~**Should `parallelGroups` account for resource constraints?**~~ **Resolved (OQ-019)**: No for v1 — `parallelGroups()` returns theoretical maximum parallelism. Adding resource constraints would conflate structural analysis with scheduling policy. The `maxConcurrency` prop on `Parallel` is a runtime scheduling concern handled by the reactive engine, not a structural analysis concern. If consumers need resource-aware scheduling, they can post-process `parallelGroups()` output with their own constraints. An optional `maxConcurrency` parameter can be added in v2 as a convenience, but the core analysis function stays pure.
 
 ## References