build(deps): bump dompurify from 3.3.1 to 3.3.2 in /packages/ui in the npm_and_yarn group across 1 directory - #1
Closed
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps the npm_and_yarn group with 1 update in the /packages/ui directory: [dompurify](https://github.com/cure53/DOMPurify). Updates `dompurify` from 3.3.1 to 3.3.2 - [Release notes](https://github.com/cure53/DOMPurify/releases) - [Commits](cure53/DOMPurify@3.3.1...3.3.2) --- updated-dependencies: - dependency-name: dompurify dependency-version: 3.3.2 dependency-type: direct:production dependency-group: npm_and_yarn ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Hey! Your PR title Please update it to start with one of:
Where See CONTRIBUTING.md for details. |
Contributor
This PR doesn't fully meet our contributing guidelines and PR template. What needs to be fixed:
Please edit this PR description to address the above within 2 hours, or it will be automatically closed. If you believe this was flagged incorrectly, please let a maintainer know. |
ContributorAuthor
Superseded by #5. |
dependabotBot
deleted the
dependabot/npm_and_yarn/packages/ui/npm_and_yarn-1a37318557
branch
April 14, 2026 05:00
LeXwDeX pushed a commit
that referenced
this pull request
Apr 30, 2026
LeXwDeX pushed a commit
that referenced
this pull request
Jun 5, 2026
WP1 + WP2: NodeStateMachine 完整实现（40 → 45 测试，全 GREEN） WP1 交付（40 tests GREEN）： - NodeStateMachine 类：11 个公共方法 + 本地 INodeStatePersister 扩展 - 完整 Iron Law 执行（#1 transition 验证, #2 终态不可逆, #3 事件广播, #4 持久化优先） - 测试套件按铁律 #1-#4 + 核心功能分组，覆盖正常/异常/边界 WP2 交付（40 → 45 GREEN）： - P2-1: 提取 persistAndApply() 私有 helper，消除 72 行重复（6 个写操作方法重构为单行调用） - P2-2: 扩展 types.ts::NodeEvent union 加入 node.reset，移除 as unknown as 桥接 - P2-3: 保留本地 INodeStatePersister 扩展（全仓 grep 验证无其他模块需要节点级持久化） - P2-4: NodeTransitionParams 增加 5 个 optional payload 字段（fallbackTrigger, retryCount, abortReason, upstreamFailedNode, worktreePath） - P2-5: 新增 Shadow 节点集成测试 5 个用例 - P2-6: 移除 INodeStateMachine.getSchedulableNodes()（职责属于 Scheduler，已归档） 设计决策： - D1: FAILED 作为半终态（getValidNextNodeStatuses(FAILED) 返回 [RUNNING, ABORTED]） - D2: 本地 INodeStatePersister 扩展，不污染公共 IStatePersister - D3: 事件类型按 types.ts 命名（node.started / node.pushed 而非 node.start / node.push） - D5: skipNode() 严格 from-status 验证（仅允许 PENDING/QUEUED → SKIPPED） - D6: 选择方案 C 扩展 NodeEvent union 加入 node.reset（而非删除事件） - D7: 不提升 writeNodeState/readNodeState 到公共接口（接口隔离原则） - D8: 移除 getSchedulableNodes() 方法 + 接口签名（YAGNI 原则） 代码质量： - typecheck: 0 errors - as any in source: 0（仅注释'禁止 as any'） - persistAndApply 调用点: 6 处（统一 rollback 模式） - 全量 DAG 测试: 439 pass / 5 skip / 0 fail（16 files, 零回归） Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
LeXwDeX pushed a commit
that referenced
this pull request
Jun 5, 2026
…t()) WP2 of DAG completion plan. Expands Iron Law coverage across boundaries: cross-module state machines, admin bypass reuse, persist failure rollback, and performance sanity. New file: src/dag/state-machine/__tests__/TddCoverage.test.ts (729 lines, 10 tests) Test cases: 1. Shadow full lifecycle register → PENDING → RUNNING → COMPLETED (emit [registered, started, completed]; branch aggregates completed) 2. Shadow PENDING → RUNNING → FAILED (emit chain [registered, started, failed]) 3. Shadow PENDING → COMPLETED direct jump throws InvalidNodeTransitionError (Iron Law #1: Shadow's valid transitions exclude PENDING→COMPLETED) 4. resetNode from COMPLETED → admin bypass reuse → second COMPLETED (pushed_count/fallback_count reset to 0; emit second [started, completed]) 5. resetNode from FAILED → admin bypass → PENDING → RUNNING → COMPLETED (emit [failed, reset, started, completed]) 6. readWorkflowState failure propagation — WorkflowStateMachine.transition (not getNodeState which only reads memory) — error propagates, no silent degradation, memory state unchanged 7. writeNodeState failure on specific node → StateNotPersistedError, rollback (memory unchanged; no node.started event emitted) 8. 100 WorkflowStateMachine concurrent event storm (shared EventBus, unique workflow_ids, ≤ 2000ms — actually ≈300ms in practice) 9. 1000 nodes register + query ≤ 5000ms (full chain 4.64s; query ms-level) 10. Cross NodeStateMachine shared IStatePersister — memory state isolated per instance, persister stores both without cross-pollution Implementation notes: - Test 6 uses WorkflowStateMachine.transition (the only path that calls persister.readWorkflowState) instead of NodeStateMachine.getNodeState (which is purely memory-based) - Test 8 uses real EventBus (not mock) to exercise wildcard listener path - Test 9 strictly serial register+transition to avoid state races Test results: - WP2 expansion: 10 pass / 0 fail (2065 expect(), 4.64s) - state-machine module total: 124 pass / 0 fail (was 114) - typecheck: 0 errors Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
LeXwDeX pushed a commit
that referenced
this pull request
Jun 5, 2026
WP1 + WP2: NodeStateMachine 完整实现（40 → 45 测试，全 GREEN） WP1 交付（40 tests GREEN）： - NodeStateMachine 类：11 个公共方法 + 本地 INodeStatePersister 扩展 - 完整 Iron Law 执行（#1 transition 验证, #2 终态不可逆, #3 事件广播, #4 持久化优先） - 测试套件按铁律 #1-#4 + 核心功能分组，覆盖正常/异常/边界 WP2 交付（40 → 45 GREEN）： - P2-1: 提取 persistAndApply() 私有 helper，消除 72 行重复（6 个写操作方法重构为单行调用） - P2-2: 扩展 types.ts::NodeEvent union 加入 node.reset，移除 as unknown as 桥接 - P2-3: 保留本地 INodeStatePersister 扩展（全仓 grep 验证无其他模块需要节点级持久化） - P2-4: NodeTransitionParams 增加 5 个 optional payload 字段（fallbackTrigger, retryCount, abortReason, upstreamFailedNode, worktreePath） - P2-5: 新增 Shadow 节点集成测试 5 个用例 - P2-6: 移除 INodeStateMachine.getSchedulableNodes()（职责属于 Scheduler，已归档） 设计决策： - D1: FAILED 作为半终态（getValidNextNodeStatuses(FAILED) 返回 [RUNNING, ABORTED]） - D2: 本地 INodeStatePersister 扩展，不污染公共 IStatePersister - D3: 事件类型按 types.ts 命名（node.started / node.pushed 而非 node.start / node.push） - D5: skipNode() 严格 from-status 验证（仅允许 PENDING/QUEUED → SKIPPED） - D6: 选择方案 C 扩展 NodeEvent union 加入 node.reset（而非删除事件） - D7: 不提升 writeNodeState/readNodeState 到公共接口（接口隔离原则） - D8: 移除 getSchedulableNodes() 方法 + 接口签名（YAGNI 原则） 代码质量： - typecheck: 0 errors - as any in source: 0（仅注释'禁止 as any'） - persistAndApply 调用点: 6 处（统一 rollback 模式） - 全量 DAG 测试: 439 pass / 5 skip / 0 fail（16 files, 零回归）
LeXwDeX pushed a commit
that referenced
this pull request
Jun 5, 2026
…t()) WP2 of DAG completion plan. Expands Iron Law coverage across boundaries: cross-module state machines, admin bypass reuse, persist failure rollback, and performance sanity. New file: src/dag/state-machine/__tests__/TddCoverage.test.ts (729 lines, 10 tests) Test cases: 1. Shadow full lifecycle register → PENDING → RUNNING → COMPLETED (emit [registered, started, completed]; branch aggregates completed) 2. Shadow PENDING → RUNNING → FAILED (emit chain [registered, started, failed]) 3. Shadow PENDING → COMPLETED direct jump throws InvalidNodeTransitionError (Iron Law #1: Shadow's valid transitions exclude PENDING→COMPLETED) 4. resetNode from COMPLETED → admin bypass reuse → second COMPLETED (pushed_count/fallback_count reset to 0; emit second [started, completed]) 5. resetNode from FAILED → admin bypass → PENDING → RUNNING → COMPLETED (emit [failed, reset, started, completed]) 6. readWorkflowState failure propagation — WorkflowStateMachine.transition (not getNodeState which only reads memory) — error propagates, no silent degradation, memory state unchanged 7. writeNodeState failure on specific node → StateNotPersistedError, rollback (memory unchanged; no node.started event emitted) 8. 100 WorkflowStateMachine concurrent event storm (shared EventBus, unique workflow_ids, ≤ 2000ms — actually ≈300ms in practice) 9. 1000 nodes register + query ≤ 5000ms (full chain 4.64s; query ms-level) 10. Cross NodeStateMachine shared IStatePersister — memory state isolated per instance, persister stores both without cross-pollution Implementation notes: - Test 6 uses WorkflowStateMachine.transition (the only path that calls persister.readWorkflowState) instead of NodeStateMachine.getNodeState (which is purely memory-based) - Test 8 uses real EventBus (not mock) to exercise wildcard listener path - Test 9 strictly serial register+transition to avoid state races Test results: - WP2 expansion: 10 pass / 0 fail (2065 expect(), 4.64s) - state-machine module total: 124 pass / 0 fail (was 114) - typecheck: 0 errors
LeXwDeX pushed a commit
that referenced
this pull request
Jun 7, 2026
…udit The orchestrating agent can now restructure the tail of a running workflow (add/remove/update pending nodes, bump max_concurrency) without restarting. Terminal and frozen nodes (running/completed/ failed/skipped/queued) are preserved as immutable scaffolding. Three new types in src/dag/session/types.ts: - ReplanNodePatch: partial update to a pending node - ReplanPatch: full patch shape (add/remove/update nodes, cap bump) - ReplanResult: discriminated ok/error union First real use of the dag_workflow_history SQLite table (migration 884f08e created it, now with its first consumer). Each successful replan writes exactly one row: action='replan', old_state/new_state/ change_details as parsed JSON (Drizzle mode:"json" contract honored, no double-stringify), changed_by, timestamps. Engine-level changes in src/dag/session/workflow-engine.ts: - replanWorkflow: validates frozen/mutable node partition, applies in-memory patch, runs full graph validator (≤20 nodes, max_concurrency 1..10, cycles, unresolved deps, required-preservation), atomically applies via Database.transaction, writes history row. - replanInFlight: Set<string> coordination flag + scheduleReadyNodes early-return guard to prevent scheduler from spawning nodes mid-replan. - detectCycle: module-level DFS helper for dependency graph cycle check. Service-level changes in src/dag/session/session-service.ts: - 4 new optional methods on IDAGSessionService: createHistory, deleteNode, updateNodeConfig, atomicReplan (declared optional to preserve dag-query.test.ts mocks; defensive guard in replanWorkflow). - atomicReplan wraps all 5 DB writes (DELETE removed, UPDATE modified, INSERT new, UPDATE workflow.config, INSERT history) in a single Database.transaction (first use of this API in session-service.ts). Tool-layer changes in src/tool/dagworker.ts: - Schema.Literal("replan") added to action Union. - New optional `patch` field (JSON ReplanPatch). - run() switch case "replan" that parses patch, calls workflowEngine.replanWorkflow, returns structured ok/error result. Bundle prompt updates: - src/session/prompt/dag.txt: replan paragraph (trigger keywords, what's safe/allowed, atomicity). - src/session/prompt/dagworker-reference.md: §14 "Replan protocol" (~128 lines covering schema, frozen vs mutable, validation rules, worked example, common mistakes). - src/tool/dagworker.txt: brief tool description file (was missing). Validation-before-writes atomicity: 8 validation steps (terminal workflow check, empty patch rejection, frozen-node rejection, unknown-remove/update existence guard, ≤20 node cap, max_concurrency range, unresolved deps, RequiredNodesValidator + required removal + cycle detection) all run before the first DB write. Any validation failure short-circuits via Effect.fail without touching the DB. Iron Laws compliance (verified by archgate PASS): - #1 状态机不可绕过: replan modifies only `config`/ `dependencies` JSON columns, never `status` (updateNodeMetadata precedent). - #2 终态不可逆: frozen-set (running/completed/failed/skipped/queued) covers all non-pending DAGNodeStatus values; DELETE on pending rows is not a rollback. - #3 事件必须广播: replan is structural mutation, not status transition; the dag_workflow_history row IS the durable audit. Consistent with createViolation/updateNodeMetadata precedents. - #4 持久化优先: single Database.transaction wraps all 5 DB writes. Defensive correctness: - Unknown remove/update ids rejected with descriptive error (prevents silent no-op + misleading return counts). - Empty patches rejected (prevents no-op history rows). - Namespaced dependency resolution: when u.new_dependencies present, dependencies are wfNs(d)-namespaced; when absent, existing stored deps preserved (prevents both hang and DAG-order breakage). Concurrency coordination: - replanInFlight.add at gen entry; scheduled in scheduleReadyNodes early-return; Effect.ensuring guarantees cleanup on any failure. - concurrencyRegistry.set with new_max_concurrency after atomic apply. - spawnedNodes cleanup for removed node ids. Verification: typecheck clean (baseline only); DAG session 96 pass; DAG full non-worktree 462 pass; 8 sanity greps confirm; Database.transaction usage verified; 4-block Drizzle contract (createHistory INSERT + return, atomicReplan INSERT + return) all use raw objects. End-to-end replan runtime verification requires a real LLM environment. Deferred (separate follow-up WPs): - Dedicated replan unit tests (existing 396+96 DAG tests provide regression safety but don't exercise replan code paths). - experimentalDag feature flag (user intent opposes, deferred). - Drizzle mode:json double-stringify style unification across dagNodes/dagWorkflows (pre-existing convention, separate from the correct-pattern introduced here for dagWorkflowHistory).
LeXwDeX pushed a commit
that referenced
this pull request
Jun 7, 2026
… 20/21 scenarios The replan feature (commit bd8c007) ships with full code-path coverage via the existing 96 session tests + 462 DAG suite but no dedicated tests exercising replan logic. This commit adds dedicated unit-test coverage. Architectural ruling (COMBINED path): - Path A (pure helpers) as primary — extracted 6 helpers from the replanWorkflow closure to module-level exports for direct testing. - 3 @internal module-private read getters (__internal_spawnedNodes / __internal_replanInFlight / __internal_concurrencyRegistry) for scenarios 18-20 (module-registry coordination). - Scenario 21 (history row correctness) deferred to integration tier — requires DB state inspection beyond unit-test scope. Coverage: 20/21 unit-testable scenarios, 1 deferred. Total tests added: 42 across 7 describe blocks. Session suite total: 96 existing + 42 new = 138 pass / 0 fail. Production code changes in workflow-engine.ts (pure extract-and-delegate): - 6 extracted helpers: validateReplanPreconditions, classifyReplanNodes, validateFrozenAndExistence, applyReplanPatchToConfig, validateReplanPostConfig, buildReplanDbInputs. - detectCycle (module-level, previously private) now exported for validateReplanPostConfig use and test access. - 3 @internal test-only getters at lines 313, 315, 317. - replanWorkflow body refactored to delegate to helpers in sequence (L668-695); all validation completes before atomicReplan call at L704 (sequential guard preserved). Helper signatures follow the ReplanResult discriminated-union pattern (types.ts:495-505): { ok: true, data? } | { ok: false, reason, detail? }. This avoids throwing inside pure helpers and makes test assertions simple (assert ok boolean + reason string). P0-fix test coverage (critical regression safety): - 'namespaces new_dependencies on updates' (test at L512-528): asserts ['n2'] -> [wf::n2] after applyReplanPatchToConfig. - 'preserves existing deps when new_dependencies is absent' (test at L530-553): asserts ['wf::old-dep'] -> ['wf::old-dep'] when patch omits new_dependencies field (the existing-deps fallback). - 'namespaces add_nodes dependencies for DB layer' (test at L555-570): asserts add_nodes deps receive the same wfNs treatment as updates. Behavioral tests for scenarios 18-20 (module registry coordination): - Use beforeEach to clear registries via the @internal getters (Set/Map mutable types — ReadonlySet would break .delete() test cleanup). - Assert .has().size().get() on module state AFTER patch application (not just 'no exception thrown') — real state verification. Sequential guard preserved: validateReplanPostConfig at L691 is the last validation before atomicReplan at L704. Effect.fail semantics from helpers short-circuit the Effect.gen before any DB writes. Iron Laws re-verified: - #1 state-machine only: replan modifies only config/dependencies JSON columns, never status. - #2 terminal irreversible: frozen-set covers all non-pending states. - #3 event broadcast: replan is structural mutation, not status transition; dag_workflow_history row is the audit (event emission is a pre-existing gap noted but not blocking per archgate). - #4 persist first: atomicReplan uses Database.transaction for 5 atomic writes. Verification: typecheck 0 errors; 138/138 session tests pass; 504/504 non-worktree DAG tests pass; all sanity greps (7 helpers + 3 internal getters + 6 helper call sites + sequential-guard ordering) match expected patterns. Deferred (separate follow-up WPs): - Scenario 21 — history-row DB-state inspection (integration tier). - detectCycle @internal JSDoc (INFO #1 from review #2, optional). - Test n1/n2/n3 scope hygiene refactor (INFO #5, currently safe). - Iron Law #3 replan event emission (pre-existing gap, tracked).
LeXwDeX pushed a commit
that referenced
this pull request
Jun 7, 2026
…ron Law #2 compliance) Fixes critical gap where DAG workflows never converged to completed/failed status: all successful workflows were stuck in 'running' state until the 10-minute executor timeout force-cancelled them. This violated Iron Law #2 (terminal states are irreversible) by leaving workflow.status permanently mutable, and violated Iron Law #3 by suppressing workflow.completed events (downstream consumers like required-nodes-monitor never received them). Root cause identified in audit: handleNodeCompletion / handleNodeFailure (both in workflow-engine.ts) only updated node status and scheduled next batch — never inspected node-level convergence to drive workflow.status. buildSessionWorkflowEvent(session-service.ts:102) had a 'completed' case proving the design expected this transition, but implementation omitted it. Fix adds 3 helpers to workflow-engine.ts within engine.make closure: 1. findPendingDescendants(allNodes, failedNodeId) — module-level pure function. Computes reverse dependency graph, BFS from failedNodeId, returns all reachable pending descendants. Used by cascadeSkipDownstream to identify blocked downstream nodes before scheduling. 2. cascadeSkipDownstream(workflowId, failedNodeId) — closure helper. Marks all pending descendants as 'skipped' (valid transition per session- service.ts:70 state table). buildSessionNodeEvent(session-service.ts:147) already emits node.skipped events (Iron Law #3 satisfied). 3. maybeFinalizeWorkflow(workflowId) — closure helper. Idempotent guard + convergence detector: - SESSION_TERMINAL = ['completed', 'failed', 'cancelled'] local const (Session-layer DAGWorkflowStatus; avoids Core-layer isWorkflowTerminal Status import which is type-incompatible per ARCHITECTURE.md §8.c) - List nodes, detect whether any pending/queued/running remain - If all nodes terminal: any required node failed → 'failed', else → 'completed' - Calls sessionService.updateWorkflowStatus which runs persist-first (Iron Law #4) and emits workflow.completed / workflow.failed events via buildSessionWorkflowEvent (Iron Law #3 satisfied). Injection points: - handleNodeCompletion: append maybeFinalizeWorkflow(workflowId) after scheduleReadyNodes(workflowId). - handleNodeFailure: restructured to 5-step sequence: 1. updateNodeStatus(failed) 2. createViolation with conditional type — required_node_failed when node.config.required === true, else execution_failed (both present in DAGViolationType union types.ts:226-235) 3. yield* cascadeSkipDownstream(workflowId, nodeId) ← NEW 4. scheduleReadyNodes(workflowId) (schedule independent branches) 5. maybeFinalizeWorkflow(workflowId) ← NEW cascadeSkipDownstream MUST precede scheduleReadyNodes so maybeFinalize doesn't encounter stuck-pending downstream nodes (otherwise workflow would still fail to converge). Concurrency safety: - Idempotent double-barrier: spec-layer SESSION_TERMINAL.includes + service-layer getValidNextSessionWorkflowStatuses returns [] for terminal states. Either guard alone is sufficient; both together make fork races benign. - cascadeSkipDownstream only touches status === 'pending' nodes, never racing with already-forked spawnReadyNode fibers that have pushed nodes to running (those are filtered out in findPendingDescendants). - Effect.catchCause(() => Effect.void) wraps both helpers so a failing convergence attempt never surfaces as a workflow-engine error. Archgate spec-v2 verdict: PASS (all 4 iron laws + §8.c Session-layer isolation + type-safe conditional violation type + BFS cascade correctness). Test coverage — scenario-22-workflow-finalize.test.ts: Scenario 22a/22b/22c: findPendingDescendants pure-function tests — linear chain, running-block, diamond dependency. Scenario 23: required node failed → workflow = failed; downstream pending nodes auto-skipped via cascade. Scenario 24: optional node failed + all required completed → workflow = completed (optional failure only records violation, doesn't block). Scenario 25: all required completed → workflow = completed. Scenario 26: idempotent guard — manually cancelled workflow stays cancelled when late node completion arrives (maybeFinalize no-op). Integration tests bypass engine.startWorkflow (whose Effect.forkDetach doesn't schedule fibers under Effect.runSync) and simulate the real executor path directly via service.updateWorkflowStatus(running) + service.updateNodeStatus(running) per node, then exercise handleNodeCompletion/handleNodeFailure. Verification: typecheck 0 errors; scenario-22 file 7 pass / 0 fail; full session suite 146 pass / 0 fail (139 existing + 7 new); 139 existing regression tests all pass (zero regression). No production as any introduced. No new schema migration. No Core-layer imports added. DAGViolationType type-safe conditional via existing union. Closes the DAG workflow lifecycle gap: workflow.status now converges to terminal state as soon as all nodes complete, emitting the expected workflow.completed event so downstream subscribers (required-nodes- monitor, bus bridge, TUI/HTTP consumers) can observe finality. Iron laws audit — all 4 satisfied: #1 State machine API: updateWorkflowStatus / updateNodeStatus #2 Terminal irreversible: idempotent guard + service-layer validation #3 Event broadcast: buildSessionWorkflowEvent / buildSessionNodeEvent #4 Persist-first: service-layer DB write before event emission
LeXwDeX pushed a commit
that referenced
this pull request
Jun 7, 2026
…ror-log cleanup) Follow-up to f2b78b4 — close 3 remaining unlogged Effect.ignore sites that the review advisory (#1,#2,#3) flagged as consistency gaps with the other 7 tapError-prefixed sites. ## L457 updateNodeMetadata (pre-running timing fix) Chat session_id metadata write was best-effort fire-and-forget. If the DB write fails, the child session still executes (correct behavior), but there was no trace of the failure for post-mortem debugging. Now logs [DAG] node metadata update failed: <err> before ignoring. The child session executes normally either way (no behavior change). ## L565 createViolation inside catchCause The spawn-infra-failure case already logged debug about the original cause (L567), but if createViolation itself failed, the AUDIT TRAIL was silently lost — and this is exactly when audit trail is most valuable (when node spawn itself failed, not just the node execution). Now logs [DAG] violation creation failed for <nodeId>: <err> before ignoring. The outer logDebug still reports the original failure; this adds the secondary-failure trace. ## L592 cascadeSkipDownstream updateNodeStatus('skipped') This one had a dual problem: (a) Inner updateNodeStatus Effect.ignore was unlogged — DB write failure silently left downstream nodes in 'pending' state → maybeFinalizeWorkflow detects hasInProgress=true and never converges → workflow stuck in 'running' forever. (b) Outer catchCause(() => Effect.void) silently swallowed any unexpected error in the entire helper (listNodes failure, etc.) Fix applies both: - Inner: tapError before ignore with node_id context - Outer: catchCause now logs the squashed cause instead of silent void - Bonus: cascade-skip updateNodeStatus literal now uses `satisfies UpdateNodeStatusInput` to match the cleanup done in f2b78b4 (R4 as-any removal) across the rest of the file ## Scope Single file, surgical edits: packages/opencode/src/dag/session/workflow-engine.ts - L456-460 (updateNodeMetadata block) - L563-572 (createViolation inside catchCause) - L590-598 (cascadeSkip inner + outer) ## Verification - typecheck: 0 errors (exit 0) - session tests: 175 pass / 0 fail / 348 expect() (no test changes; log additions are behavior-less for assertion purposes) ## Remaining status After this commit, EVERY Effect.ignore site in workflow-engine.ts is preceded by a tapError log. No silent failure sites remain. This closes review advisory #1, #2, #3 from the previous WP (f2b78b4).
LeXwDeX pushed a commit
that referenced
this pull request
Jun 7, 2026
Reworks all DAG documentation examples to match the canonical JSON schema defined by DAGConfig/DAGNodeConfig in src/dag/session/types.ts. ## Motivation types.ts:60-84 JSDoc explicitly declares DAGConfig/DAGNodeConfig as the single canonical source of truth and states that every other document must stay consistent with these interfaces. Prior commits (aec0709, f0c35fd) fixed the runtime prompts (dag.txt, dagworker-reference.md, dag-worker.txt, dag-ctl.txt) but left the broader user-facing docs (USER_GUIDE.md / OVERVIEW.md / TUI design doc) full of YAML-style field names that don't match the engine's actual JSON input schema. Users copying those examples verbatim would hit runtime JSON.parse() / schema validation errors. ## Field mapping applied across all 7 files | YAML-style (removed) | Canonical JSON (adopted) | |---|---| | branches[].nodes / branches[].name | nodes: DAGNodeConfig[] (flat array, no branches concept) | | type: required / optional / shadow | required: true / false (boolean) | | name: (sole identifier) | id + name (separate) | | agent: <name> | worker_type: "<name>" | | task: "..." | worker_config: { prompt: "..." } | | depends_on: [...] | dependencies: [...] | | timeout_sec: N | timeout_ms: N*1000 | | max_retries: N | retry: { max_attempts: N, delay_ms: <number> } | | skip_on_failure / fallback / system.sandbox / constraints.* | Removed (not in canonical schema) | ## File-by-file changes ### packages/opencode/src/dag/USER_GUIDE.md Complete rewrite of 12 YAML code blocks (L67-99, L120-135, L143-162, L170-188, L197-209, L227-243, L249-257, L274-283, L402-431, L435-462, L466-491) to canonical JSON. Removed system.sandbox / constraints / shadow-node / fallback sections. Added L65 canonical schema disclaimer: "> **Canonical schema**: DAG 工作流配置的唯一定义来源是 DAGConfig / DAGNodeConfig 接口 (packages/opencode/src/dag/session/types.ts)。本文档所有示例均 使用该 JSON schema。" ### docs/dag/OVERVIEW.md Rewrote L210-247 YAML code block to JSON. Replaced 5 prose "YAML 配置" references with "JSON 配置" at L30, L126, L274, L305, L438. ### docs/design/008-tui-dag-integration.md Replaced depends_on with dependencies in markdown code block (L253, L258), TypeScript interface at L280, comment at L320, and tsx reference at L536. ### packages/opencode/src/command/template/dag-worker.txt 5 prose YAML→JSON wording fixes at L9, L38, L90, L101-102. Removed standalone "YAML is illustrative only" disclaimer at L104 since all examples within this file already use canonical field names; L109 canonical Worker Type Resolution note kept. ### packages/opencode/src/command/template/dag-ctl.txt L15 "创建/编辑 YAML 配置" → "JSON 配置"; L158 same. L54 removed half-sentence. ### packages/opencode/src/session/prompt/dag.txt L59 removed half-sentence (canonical JSON disclaimer already intact at L51). ### packages/opencode/src/session/prompt/dagworker-reference.md L200 removed half-sentence (canonical JSON disclaimer already intact). ## Audit-only (not modified — confirmed clean) - README.md (root, DAG section) — no YAML code blocks, no depends_on, no YAML-style field names - packages/opencode/src/command/template/dag-template.txt — no YAML-style field names ## Exceptions preserved - dag-worker.txt code blocks kept in yaml fences (format only; all field names inside are canonical) - OVERVIEW.md prose "Fallback 策略"/"支持 Fallback 机制" / `fallback_chain` references remain — these refer to group-manager runtime concept or runtime execution context fields, not to DAGNodeConfig. Review flagged as INFO. - dag-worker.txt L109 "YAML 示例仅为说明" kept as Worker Type Resolution general note. ## Verification (verify agent PASS) - typecheck: 0 errors - session baseline: 182/0 pass - template library: 20/0 pass - P0a regression (worker_type validation): 3/0 pass - DAG broader: 568 pass / 6 skip / 17 PRE-EXISTING worktree timeouts - grep 8/8 negative checks all 0 matches: - depends_on / branches: / type: required|optional|shadow / agent:/task: / timeout_sec / max_retries / skip_on_failure / constraints. - 4/4 positive checks present: - canonical disclaimer at USER_GUIDE.md:65 - 33x worker_type / 33x worker_config / 31x "dependencies" ## Review INFO findings (deferred) - INFO #1: OVERVIEW.md L181,L280 max_fallback_chain / fallback_chain are runtime model fields retaining "fallback" terminology after node-level fallback was removed. To be cleaned when runtime schema is further aligned. - INFO #2: OVERVIEW.md L436,L452 prose "Fallback 策略" refers to engine capability, not DAGNodeConfig.fallback field. Same follow-up as INFO #1. ## Scope - 7 allow-list files modified exactly - Zero .ts/.tsx changes - Zero test changes - README.md (root) and dag-template.txt not touched (clean per audit) - Translation README_<LANG>.md files intentionally out of scope (separate translation WP) ## Architecture gate: PASS types.ts JSDoc already declares docs must match interface → hard constraint exists → not a NEEDS_DESIGN situation. The rewrite simply brings docs into compliance with the existing declared contract.
LeXwDeX pushed a commit
that referenced
this pull request
Jun 9, 2026
- session-service.ts:81 case 'running' returns [completed, failed, pending] (node state transition extended per state machine, not bypassed - Iron Law #1 upheld) - types.ts:43 node transition comment updated with 'running → pending (recovery reset — orphaned running node, WP-A3)' - recovery.ts:168-170 step 4.5 resetRunningNodes call between registerEngine (step 4) and scheduleReadyNodes (step 5) — ensures reset nodes are picked up by scheduler on first pass, not relying on daemon fallback - recovery.ts:190-229 resetRunningNodes internal function: iterates running nodes → updateNodeStatus via Session path → appendNodeLog with executionPhase='recovery_reset' (INFO 5) - session-service.test.ts 3 assertion updates (running→pending from illegal to legal, non-deletion of negative tests) - New tests: scenario-24-running-node-resume.test.ts (4 tests: reset happy path + reschedule after reset + transition legality + mixed state isolation) - Assembly timing: reset in resumeOrphanWorkflow after registerEngine and before scheduleReadyNodes (INFO 2) - isNodeTerminalStatus NOT modified (running/pending/queued all non-terminal, per archgate constraint 3) - INFO 3: buildSessionNodeEvent does not emit node.reset for pending — current behavior preserved, optional enhancement deferred - INFO 4: child session orphans abandoned in DB — at-least-once semantics accepted, documented - Regression: scenario-23 3/3, scenario-24 4/4, recovery 4/4, session-service 95/95, DAG session 234/234, DAG full 53/53, typecheck 0 errors - Docs: 009 spec §2 feature A marked COMPLETE + §7 WP-A3 degraded to stable-state summary - Feature A (engine persistence / auto-resume) now fully delivered (WP-A1 + WP-A2 + WP-A3)
LeXwDeX pushed a commit
that referenced
this pull request
Jun 9, 2026
- workflow-engine.ts: cascadeSkipDownstream parameter rename failedNodeId -> triggerNodeId + add triggerType: 'upstream_failure' | 'condition_false' (default 'upstream_failure' for backward compat)
- workflow-engine.ts: logData key failed_node_id -> trigger_node_id + trigger_type field; logMessage distinguishes failure vs condition skip
- workflow-engine.ts: scheduleReadyNodes consumes skipCandidates (4 steps: state-machine skip -> createViolation(type:'condition_skipped', details:{trigger:'condition_false', condition}) -> safeAppendLog(executionPhase:'condition_skip') -> cascadeSkipDownstream(triggerNodeId, 'condition_false')), pre-spawn to avoid running->skipped illegal transition
- workflow-engine.ts: maybeFinalizeWorkflow called after skip processing (idempotent guard for scheduleReadyNodes + handleNodeCompletion dual call sites)
- types.ts: DAG_VIOLATION_TYPES append 'condition_skipped'
- i18n.ts: VIOLATION_TYPE_LABEL add condition_skipped EN/translation (Record<DAGViolationType, string> type completion)
- New tests: scenario-25-conditional-skip.test.ts (6 DB-level integration tests: single node skip / downstream cascade / multi-dependency not-cascaded / terminal convergence / shared downstream overlap I3 / condition vs failure comparison)
- INFO I1-I4 all addressed: parameter generalization (I1) / upstream_failed_node left empty with violation.details bearing real distinction (I2) / findPendingDescendants BFS re-read filters already-skipped (I3) / condition_skip vs cascade_skip executionPhase with trigger_type distinguishing (I4)
- Archgate 7 constraints all honored: state-machine via sessionService.updateNodeStatus (iron law #1) / skipped is terminal irreversible (iron law #2) / pending->skipped legal transition / required guarded by WP-B1 schema / maybeFinalizeWorkflow convergence non-blocking / findPendingDescendants reuse / violation+log dual-track audit
- Test 3/5 fixture uses ROOT predecessor node single-phase design to avoid triggering pre-existing latent defects (getReadyNodes not filtering skipped; updateNodeStatus throw in Effect.sync becoming defect — both protected by skippedNodeIds + inFlight filter + state-machine reject skipped->running)
- Regression: scenario-25 6/6 + node-condition-eval 56/56 + node-condition-schema 18/18 + scenario-22 7/7 + scenario-23 3/3 + scenario-24 4/4 + DAG session 314/314 + DAG core 53/53 + typecheck 0 errors
- Latent defects (pre-existing, not in WP-B3 scope): documented as review INFO, protected by three-layer defense, not affecting WP-B3 functional correctness
- Docs: 009 spec §7 WP-B3 degraded to stable-state summary
- Feature B (conditional branching) now fully delivered (WP-B1 + WP-B2 + WP-B3)LeXwDeX pushed a commit
that referenced
this pull request
Jun 9, 2026
…D3, feature D complete)
- workflow-engine.ts: installSubdagLifecycleBridge + cleanupSubscriptions + __internal_subdagSubscriptions (test-only) + SubdagSubscriptionState interface + module-level subdagSubscriptions Map
- 4 unsubscribe paths: workflow.completed / workflow.failed / workflow.cancelled / timeout
- 3 defensive cleanup paths: handleNodeCompletion top / handleNodeFailure top / cancelWorkflow cascade
- settle() closure guard: idempotency against event-vs-timeout race
- spawnReadyNode 'dag' dispatch block: adds updateNodeMetadata({chat_session_id}) + installs bridge synchronously after bootstrap returns (avoids missed-event window; early return on bootstrap failure)
- Event filter by event.workflow_id === childWorkflowId (ARCHITECTURE.md §8.a)
- Parent-child completion mapping: workflow.completed -> handleNodeCompletion(parent, node, subWfId); workflow.failed/cancelled -> handleNodeFailure(parent, node, Error)
- cancelWorkflow: cascades to sub-DAG running nodes (DB-driven via node.metadata.chat_session_id + listWorkflowsByChatSession + recursive cancelWorkflow)
- Timeout path: createViolation (subdag_timeout) -> cancelChildWorkflow -> handleNodeFailure (strict ordering: DB record before state changes)
- session-service.ts: getEventBus() export (symmetric with setEventBus, for workflow-engine subscription)
- types.ts: DAG_VIOLATION_TYPES append 'subdag_timeout'
- limits.ts: DEFAULT_SUB_DAG_TIMEOUT_MS = 1_800_000 (30 min) const with JSDoc
- i18n.ts: 'subdag_timeout' bilingual (en + zh) label
- New tests: scenario-27-subdag-lifecycle.test.ts (5 DB integration tests):
- Test A: child completed -> parent completed + cleanup
- Test B: child failed -> parent failed + violation + cleanup
- Test C: parent cancel -> child cascade cancelled -> async callback parent node failed + cleanup
- Test D: timeout (80ms short) -> parent failed + subdag_timeout violation + child cancelled + cleanup
- Test E: 4 paths joined no leak (sequential validate subscriptions.size === 0)
- Archgate 8 constraints all honored:
- AGENTS.md §0.2 event broadcast unified (getEventBus shared IEventBus, no custom channels)
- AGENTS.md Iron Law #1 state-machine un-bypassed (all via sessionService.updateNodeStatus)
- AGENTS.md Iron Law #2 terminal irreversible
- AGENTS.md Iron Law #3 event must broadcast
- ARCHITECTURE.md §8.a IEventBus filter by workflow_id
- ARCHITECTURE.md §11 no Core path instantiation (only type/interface refs)
- 009 §3.3 event bridge + depth ≤ 3
- 009 §7 WP-D3 (event bridge + timeout + cancel cascade + fiber no leak; reuses existing handleNodeCompletion/handleNodeFailure)
- INFO 1-5 all addressed: events already existed (INFO 1); filter by workflow_id (INFO 2); cancelWorkflow additive cascade (INFO 3); 4+3 cleanup paths (INFO 4); dag-bus-bridge translator unchanged per workflow_id (INFO 5)
- Regression safety: 13/13 checks pass (all 7 core functions intact + 3 new exports defined + 3 config types defined + subdag_timeout in violations + Core path 0 imports)
- Test regression: scenario-27 5/5 + scenario-27a 5/5 + subdag-dispatch 8/8 + scenario-22 7/7 + scenario-21 1/1 + scenario-23 3/3 + scenario-24 4/4 + scenario-25 6/6 + scenario-26 3/3 + dagworker 3/3 + core-start 4/4 + DAG session 391/391 + DAG core 53/53 + typecheck 0 errors (total 454 tests)
- Review INFO 11 P2-P5 non-blocking (chat_session_id missing silent skip / any type / destructuring style / waitMs async / test cleanup / assertion granularity / map override / getEventBus undefined no logWarning / JSDoc ok / i18n ok / section separator ok)
- Docs: 009 spec §2 feature D marked COMPLETE + §7 WP-D3 degraded to stable-state summary
- Feature D (sub-DAG) now fully delivered (WP-D1 + WP-D2 + WP-D3); all 4 features in 009 doc completed (A/B/C/D)LeXwDeX pushed a commit
that referenced
this pull request
Jun 10, 2026
INFO #1 — Remove dead WorktreeManagerTag re-export from dag/layer.ts. No external consumer found (rg 'WorktreeManagerTag from' returns 0 matches across all packages/opencode/src). The import on line 11 is still required for line 42 (Layer.effect assembly). INFO #2 — Add stepWorkflow test in data.test.ts for parity with pause/resume/cancel/repl an/create wrappers (mutation wrappers suite was missing the P2-B step case). Test uses identical inline mock client + calls-capture pattern, asserts workflowId passthrough. data.test.ts 76 → 77 pass. INFO #3 — Document worktree-manager/tags.ts pattern in AGENTS.md §7 as a known workaround for circular Effect Service tag dependencies. Mentions Layer.suspend alternative (provider.ts:1852 as precedent) as first-resort before extracting leaf tag file.
LeXwDeX pushed a commit
that referenced
this pull request
Jun 13, 2026
…owing Bug observed: DAG UI showed all nodes as pending even though child agents were running and finished their work. One child agent's final message was: 'DAG node status is pending, cannot call node_complete'. Root cause: spawnReadyNode updated pending→running in DB via updateNodeStatus(). If that DB write threw (e.g. state machine rejected, connection issue), the error was swallowed by Effect.ignore and the code continued to prompt the child session anyway. Child ran to completion with the node still persisted as pending. When child called node_complete to signal 'completed', state machine rejected pending→completed (the only legal pending-transitions are queued/running/skipped). This affected both the regular-node and sub-DAG dispatch branches. Fix: - Remove Effect.ignore on both running-write sites in spawnReadyNode. - Use Effect.result with Result.isFailure branch. - Introduce module-internal handleSpawnFailure helper that: 1. logs (executionPhase: running_status_write_failed / subdag_running_write_failed) 2. records violation (execution_failed) 3. writes the only legal pending-terminal state: skipped (A-layer execution-core.ts:382-383; pending→failed is forbidden) 4. removes from spawnedNodes (avoid permanent re-spawn blockage) 5. cascadeSkipDownstream to skip dependent downstream pending nodes 6. resolveStepFailed in stepMode (release deferred, avoid stepWorkflow hanging — known pitfall from hindsight memory) 7. scheduleReadyNodes (critical for max-concurrency < ready-count; without this the workflow gets stuck running — review round-1 BLOCKING fix) 8. maybeFinalizeWorkflow (convergence) - stepMode branch returns before scheduleReadyNodes (matches handleNodeFailure pattern — workflow must remain paused). Constraints preserved: - Iron law #1: state changes go through sessionService.updateNodeStatus - Iron law #2: terminal states irreversible (skipped is terminal) - A-layer state machine (execution-core.ts:378-394): pending legal terminal transition is only 'skipped' (queued/running are non-terminal, failed is illegal) - handleSpawnFailure stays module-internal (not exported), no public API change. Regression coverage (scenario-34): (a) pending→running write fails → node ends skipped, no child prompt dispatched, spawnedNodes cleaned, log emitted (b) pending→running write succeeds → baseline path unchanged (c) stepMode Deferred release on spawn failure → stepWorkflow no hang (d) Concurrency budget (max_concurrency=2, 5 ready) → after A fails, sibling B/C get scheduled (falsifiable: revert fix → expect(0).toBe(2)) Full test suite: 4126 pass / 4 fail (pre-existing unrelated: 1 WSL chmod, 3 subprocess 30s timeouts) / 22 skip / 1 todo. typecheck: 0 errors. DAG session: 597/597. DAG TUI: 340/340. Workflow: archgate PASS (2 rounds), implement (2 rounds after 1st review BLOCKING), verify (2 rounds), review (2 rounds), patcher READY.
LeXwDeX pushed a commit
that referenced
this pull request
Jun 13, 2026
…failed Problem observed: When a DAG workflow fails, the parent LLM session has no way to know. The user must manually ask 'what happened to my workflow' — the main agent is completely unaware until prompted. This breaks the 'agent as orchestrator' mental model and forces human-in-the-loop to surface the failure. Design principle (user-specified): - If the parent session is busy (in the middle of a user turn), just inject the failure notification into its message history — do not interrupt. - If the parent session is idle, inject the notification AND wake it up (via ops.loop) so the LLM can proactively respond. This mirrors the proven pattern in task.ts's injectBackgroundResult: a background fiber can append a synthetic user message to a foreground session's history without disrupting the user's current turn. Implementation: - Capture SessionStatus.Service in workflow-engine.ts make() using the existing capturedAgentService/capturedChatSessions pattern (same B→B layer, no new dependency direction). - New module-internal helper: notifyParentOfFailure - Queries parent session status via capturedSessionStatus.get() - Injects synthetic text part with structured XML-tagged failure summary, synthetic:true metadata - If parent status.type === 'idle', forks ops.loop to wake it (fire-and-forget via Effect.forkDetach so it doesn't block DAG convergence) - Call site: maybeFinalizeWorkflow, after updateWorkflowStatus succeeds, only when targetStatus === 'failed' - Best-effort throughout: any internal failure (prompt/loop/session lookup) is caught and silently ignored — never blocks workflow convergence. Constraints preserved: - Iron law #1/#3/#4: updateWorkflowStatus persists + emits EventBus event BEFORE notifyParentOfFailure runs; notification is purely a side-effect. - Iron law #2: no state reversals; notification is read-only. - Idempotency: maybeFinalizeWorkflow's existing terminal-status guard (already in SESSION_TERMINAL) ensures the notification fires at most once per workflow lifetime. - stepMode suppression: handleNodeCompletion/Failure return before calling maybeFinalizeWorkflow when stepMode is active — notification naturally doesn't fire during step-mode. Regression coverage (scenario-35, 6 cases): (a) workflow failed + parent idle → prompt(noReply) called 1x + loop called 1x (b) workflow failed + parent busy → prompt(noReply) called 1x + loop NOT called (c) workflow completed → notification NOT triggered (d) workflow already cancelled (terminal guard) → no duplicate notification (e) SessionStatus.Service unavailable → best-effort return, workflow still converges to failed (f) PromptOps unavailable → best-effort return, workflow still converges to failed Each case asserts synthetic:true + 'dag_workflow_failed' in text + workflowId present — verifies structured content, not just call count. Full test suite: 4142 pass / 21 fail (all pre-existing WSL/subprocess/ network issues, unrelated to WP1). typecheck: 0 errors. DAG session: 603/603. DAG TUI: 340/340. Workflow: archgate PASS, implement (1 round), verify (1 round), review (1 round, 0 blocking / 2 info — 1 whitespace residue fixed in this commit, 1 agent:'main' hardcoding acknowledged as design debt for future parent-agent lookup improvement), patcher PRE-EXISTING_ISSUE accepted.
LeXwDeX pushed a commit
that referenced
this pull request
Jun 13, 2026
…cy recovery Problem observed: When a DAG node fails, the workflow immediately terminalizes to 'failed' and cascades skip to all pending downstream nodes. The user and parent LLM agent have no way to recover from transient failures — the only option is to create a brand new workflow, losing all completed work. This breaks the 'orchestrator agent' model where the agent should be able to observe failures and replan around them. Design intent (user-specified): - When a node is configured with failure_policy='recoverable' and fails at running state, the node enters 'recoverable' non-terminal state instead of 'failed'. - The workflow remains in running/paused state, not terminalizing. - Downstream pending nodes remain pending and do not cascade skip. - The parent LLM agent can later observe the recoverable failure via notification (WP4) and issue a replan to replace the recoverable node (WP3). This establishes the foundational state machine for all subsequent WPs. Iron Law #2 is preserved: 'failed' remains absolutely terminal; 'recoverable' is a new non-terminal state with strict outgoing transitions defined by policy, not ad-hoc mutation. Implementation (core 5 files): - DAGNodeStatus union widened: + 'recoverable' (types.ts:47-53) - DAGNodeConfig: new optional field failure_policy: 'fail' | 'recoverable'; default 'fail' preserves backward compatibility - State machine (execution-core.ts): - running → recoverable (legal when failure_policy='recoverable') - recoverable → pending (reset for re-run) or failed (abandon) - recoverable → running NOT legal (must reset first to prevent bypassing validation) - pending → recoverable NOT legal (only running can recoverable) - recoverable is NOT in isNodeTerminalStatus (types.ts:584-586) - computeFinalWorkflowStatus (execution-core.ts:105-116): - hasInProgress check now includes recoverable; workflow stays running when recoverable nodes present - getReadyNodes (execution-core.ts:76-90): excludes recoverable nodes from ready set (like running/completed/failed/skipped) - classifyReplanNodes (execution-core.ts:230-241): recoverable is FROZEN in WP2. WP3 will relax this to make recoverable nodes removable via replan for replacement. - calculateWorkflowProgress (types.ts:570-601): new recoverable counter in DAGWorkflowProgress.all_nodes and .required; total === sum(status counts) invariant preserved - updateNodeStatus timestamp (session-service.ts:696-701): recoverable sets end_time (execution ended) but NOT completed_at (only completed/failed set completed_at) - handleNodeFailure (workflow-engine.ts:1489-1555): - Reads node.config.failure_policy before status write - If 'recoverable': updateNodeStatus → recoverable, NO cascade skip, still calls scheduleReadyNodes (other branches may proceed) + maybeFinalizeWorkflow (returns null since recoverable is in-progress) - If 'fail' or unset: existing running→failed+cascade behavior unchanged (zero regression) Constraints preserved: - Iron Law #1: all transitions still go through updateNodeStatus gatekeeper (session-service.ts:675-682) - Iron Law #2: failed still terminal, immutable - Iron Law #4: persist-before-emit invariant preserved - Backward compat: failure_policy omitted ≡ 'fail' semantics - No DB schema migration: status column is free text, accepts 'recoverable' literals directly Downstream type propagation (8 files): - TUI glyphs.ts: iconRecoverable='?' placeholder (WP4 will refine) - TUI i18n.ts: NodeStatus type widened, NODE_STATUS_ZH recoverable='可恢复' - TUI status.ts: NODE_STATUS_ICON recoverable=?, nodeStatusColor recoverable→theme.warning (same as running/queued) - TUI tests (node-dialog/renderer.test): fixture Records updated to include recoverable:0 entries - recovery.ts recoverNodeTargetStatus: recoverable→failed for orphan recovery (process restart loses the agent context that would issue a replan; 'failed' is the safest terminal default) - HTTP API DagNodeStatus schema: widened to include 'recoverable' - execution-core.test.ts: getValidNextSessionNodeStatuses running expectation now includes 'recoverable' Test coverage (3 test files, scenario-36 + 2 fixture updates): - scenario-36-recoverable-basics.test.ts (new, 9 cases): (a) regression baseline: default failure_policy='fail' → running → failed + cascade skip downstream pending (b) running → recoverable: failure_policy='recoverable' + node fail → recoverable, no cascade skip (c) downstream pending preserved: upstream recoverable + downstream C pending → C stays pending, not cascade skipped (d) workflow not finalize: computeFinalWorkflowStatus returns null when recoverable nodes present, workflow stays running (e) recoverable not rescheduled: getReadyNodes excludes recoverable, scheduleReadyNodes skips it (f) state machine illegal transition guards: recoverable→running rejected, pending→recoverable rejected — only running can transition to recoverable, and only to pending or failed (g) legal transitions: recoverable→pending (reset) and recoverable→failed (abandon) both succeed (h) isNodeTerminalStatus('recoverable') === false explicit (i) handleNodeFailure default path (failure_policy omitted) is unchanged — backward compat regression guard - execution-core.test.ts + session-service.test.ts (fixture updates): validTransitions mapping, buildSessionNodeEvent null case for recoverable, isNodeTerminalStatus negation, DAGNodeStatus enum completeness — all synchronized with the new union member Full test suite: 4156 pass / 21 fail (all pre-existing WSL chmod + subprocess timeout + WorktreeManager WSL I/O timeout; zero regressions from WP2 changes). typecheck: 0 errors. DAG session: 615/615. DAG TUI: 342/342. Workflow: archgate PASS, implement (3 rounds: core + type-propagation + test-coverage-gaps), verify (1 round), review (1 round, 0 blocking / 4 info — all 4 test coverage gaps fixed), patcher READY.
LeXwDeX pushed a commit
that referenced
this pull request
Jun 14, 2026
…/replacement
Problem observed:
WP2 introduced 'recoverable' non-terminal node state, which lets the
parent LLM agent observe failures and pause the workflow. However, the
existing replanWorkflow API still rejects any attempt to remove a
recoverable node — classifyReplanNodes lumps 'recoverable' into the
'frozen' bucket (line 246), making recoverable nodes immune to
removal. The user/agent has no mechanism to replace a failed
recoverable node with a retry alternative, leaving the workflow
permanently stuck running with a recoverable node blocking completion.
This is the 'known unavailable defect' in the DAG system.
Design principle (user-specified):
The 'recoverable' state exists specifically to enable retry via
replan. Therefore replanWorkflow must allow removing recoverable nodes
(plus their pending downstreams if desired) and inserting replacement
nodes that re-engage the workflow scheduler. The replacement path
must be remove+add, NOT in-place update — in-place mutation of a
failed node's config/dependencies would constitute a state-machine
bypass (the node never transitioned through pending → running again).
Implementation (execution-core.ts, workflow-engine.ts):
- classifyReplanNodes (execution-core.ts:252-264): Three-tier
classification replacing the previous frozen/mutable binary:
- frozen: queued/running/completed/failed/skipped (immutable —
cannot be removed or updated by replan)
- removable: recoverable (can be removed, cannot be updated in
place — must use remove+add replacement pattern)
- mutable: pending (can be removed or updated)
Returns {frozen, removable, mutable, frozenIds, removableIds,
mutableIds}. recoverable is now in removable (not frozen), per
WP2's own forward comment at execution-core.ts:234-240 anticipating
this relaxation.
- validateFrozenAndExistence (execution-core.ts:267-276): Signature
extended with optional-last removableIds parameter
(default=new Set<string>()). remove_nodes validator rejects
frozenIds (unchanged) but accepts pending OR recoverable ids (new
relaxation). update_nodes validator rejects frozenIds AND
removableIds (new tightening — prevents state-machine bypass via
in-place mutation of recoverable nodes). Backward-compat: optional
parameter default means all 48 existing replan.test.ts cases + 25
templates.test.ts cases continue to pass without modification
(they pass 3 args, removableIds defaults empty, no update_nodes
validation relaxation fires).
- replanWorkflow + previewReplanWorkflow call sites
(workflow-engine.ts:2044-2049, 2120-2127): Both pipelines
destructure classifyReplanNodes' 6-value return and pass
removableIds to validateFrozenAndExistence.
- replanWorkflow fork trigger (workflow-engine.ts:2203):
Effect.forkDetach(scheduleReadyNodes(workflowId)) after
replanInFlight.delete — newly added replacement nodes enter
scheduling immediately without blocking the replan return. Using
forkDetach (not fork) because: (1) the schedule fiber must survive
independent of parent fiber termination, and (2) its Effect
signature is <never> error channel, so forkDetach's
error-swallowing behavior is safe.
Constraints preserved:
- Iron Law #1 (state machine not bypassed): recoverable nodes are
physically deleted by atomicReplan.removeNodeIds
(session-service.ts:928, no status filter — validator at entrance
already guards only pending/recoverable can enter remove_nodes).
Replacement nodes are brand-new pending entities inserted by
atomicReplan.insertNodes — no state transition mutation occurs.
- update_nodes still rejects recoverable (validateFrozenAndExistence
at L271 explicitly checks removableIds).
- Iron Law #2 (terminal immutability): recoverable is non-terminal
(WP2 isNodeTerminalStatus returns false), so removing it is not
reversing a terminal state. Frozen bucket still contains
failed/completed/skipped/cancelled — those remain absolutely
immutable.
- Iron Law #3 (audit history): replanWorkflow's existing
emitWorkflowReplannedEvent (L2192) and history row write
(before L2057) continue unchanged. recoverable removal + add
replacement entries land in history naturally.
- Iron Law #4 (persist-first): scheduleReadyNodes fork happens
AFTER atomicReplan.commit (L2155) — DB state is durable before
any runtime side-effect.
Backward compatibility:
- validateFrozenAndExistence's removableIds is optional-last with
default empty Set. All 48 replan.test.ts cases + 25
templates.test.ts cases pass unchanged (they pass 3 args; empty
removableIds means no relaxation fires; behavior identical to
pre-WP3).
- spawnedNodes cleanup (workflow-engine.ts:2187) is an unconditional
loop over patch.remove_nodes IDs — no status filter needed.
recoverable IDs already enter this loop because validator admits
them to remove_nodes. Zero new cleanup code.
Test coverage (scenario-37, 7 cases):
(a) frozen regression: remove completed/failed/skipped/running/queued
still rejected (5 frozen statuses individually asserted)
(b) end-to-end replace: A completed + B recoverable + C pending
→ replan removes B+C, adds B2(dep:A)+C2(dep:B2) → B2 auto-
scheduled via forked trigger → workflow completes successfully
(c) fork trigger precision: spawnedNodes.has(B2) === true after
replan returns (proves fork actually fired)
(d) deps update path: remove recoverable B, keep pending C, update
C.dependencies=[B2] → C no longer blocked, B2 auto-scheduled
(e) state-machine non-bypass: update_nodes attempting to mutate
recoverable B's worker_config → validator rejects (reason
contains 'removable')
(f) audit history: dag_workflow_history gains row with
change_details.removed list containing recoverable node id
(g) mixed remove: remove_nodes=[pending C, recoverable B] both
accepted (mixed status combinations legal)
Updated existing test:
- scenario-36 test (i) at line 371: previously asserted recoverable
node falls in frozen bucket. Updated to assert recoverable falls
in removable bucket (the whole point of WP3). All 8 other
scenario-36 tests unchanged.
Full test suite: 4158 passed / 21 failed. All 21 failures are
pre-existing environment issues (17 WorktreeManager WSL filesystem
latency timeouts, 1 tool.write chmod test, 3 opencode run subprocess
timeout, 2 E2E deepseek-v4-pro network). Zero new failures from WP3.
Regression baselines:
- DAG session: 622/622 (1560 expect, 35 files)
- DAG TUI: 342/342 (756 expect, 16 files)
- replan.test.ts: 48/48 (114 expect)
- scenario-21-replan-history: 1/1 (19 expect)
- execution-core.test.ts: 50/50 (68 expect)
- templates.test.ts: 25/25
- scenario-36 (WP2): 9/9 (all pass with updated test i)
- scenario-37 (WP3): 7/7
typecheck: 0 errors.
Workflow: archgate (1 round, PASS with 2 advisories on optional-last
parameter order and pre-existing forkDetach semantics in workflow
engine), implement (1 round), verify (1 round), review (1 round),
patcher (1 round).LeXwDeX pushed a commit
that referenced
this pull request
Jun 14, 2026
Problem observed: WP2 gave recoverable nodes a non-terminal state (commit 67aea1d), but the user facing surfaces had only placeholder visibility: TUI showed '?' glyph with same warning color as running/queued, node-detail had no error reason (error_info was never persisted to DB), live-ticker didn't refresh (no dag.node.updated event emission), statistics panels didn't include recoverable counts, and the WP1 failure notification payload lacked structured metadata for the parent agent to act on. These gaps made recoverable failures effectively invisible to both users and the orchestrating LLM agent, defeating the retry intent of WP2/WP3. Implementation (17 files, +117/-8): G1 — glyph placeholder replaced: - glyphs.ts: iconRecoverable: '?' → '~' (pure ASCII, visually distinct from completed +/failed x/running */pending o/queued @/skipped -) - glyphs.test.ts: NODE_STATUSES constant adds 'recoverable' so ASCII guard actually covers the new status G2 — theme.recoverable color (backward-compatible): - status.ts StatusThemeColors<C>: optional recoverable?: C field added - nodeStatusColor switch: case recoverable returns theme.recoverable ?? theme.warning (themes that don't define recoverable still work) G3 — NodeDialog user-facing action hint: - node-dialog.tsx: when node.status === 'recoverable' show i18n hint '使用 dagworker replan 替换此节点' / 'Use dagworker replan to replace this node' in theme.warning color - i18n.ts: recoverable_action_hint key added (en/zh) G4/G12 — updateNodeStatus persists error_info to DB: - session-service.ts updateNodeStatus: if input.error !== undefined, write updates.error_info = input.error. DB column is JSON mode (schema.ts:36), accepts any JSON-serializable value. - persist-first preserved: DB write happens inside Database.use(...) closure, closes before eventBus.emit. - Default fail path (L1735-1755 handleNodeFailure) and recovery.ts orphan recoverable→failed path both benefit automatically (same updateNodeStatus entry point). G5 — node.recoverable platform event: - state-machine/types.ts NodeEvent union: new 'node.recoverable' variant with payload: { trigger: FallbackTrigger; error?: ... } (reuses existing FallbackTrigger semantics) - session-service.ts buildSessionNodeEvent: new case 'recoverable' returns { type: 'node.recoverable', ... } event - bridge/dag-bus-bridge.ts nodeEventToStatus: maps 'node.recoverable' event to 'recoverable' status string for downstream consumers - Live-ticker now refreshes on recoverable transitions (data.ts:657 subscribes to dag.node.updated) G6 — statistics/snapshot recoverable count: - workflow-engine.ts WorkflowStatusSnapshot: recoverableCount?: number added; getWorkflowStatus() counts recoverable nodes - dag-query.ts getWorkflowStatistics: adds recoverable to the count - query-types.ts WorkflowStatistics: recoverable: number (optional field added, backward-compatible) - renderer.tsx formatProgressSummary: outputs recoverable i18n label with theme.warning color when recoverable > 0 G7 — NodeExecutionTime.status type unification: - query-types.ts NodeExecutionTime.status: union widened to include 'queued' | 'skipped' | 'recoverable' (closes pre-existing alignment gap between query-types.ts [4 states] and data.ts [6 states]) - data.ts NodeExecutionTime.status: adds 'recoverable' to match G9 — notifyParentOfFailure metadata enrichment: - workflow-engine.ts notifyParentOfFailure metadata object adds: - dag_failed_nodes: string[] (array of failed node ids) - dag_reason: string (coarse failure reason tag) - dag_trigger_reason: string ('exec_failed' etc.) - Backward-compatible: only new additive fields, existing dag_workflow_id and dag_event keys unchanged. Iron laws preserved: - #1 State machine not bypassed: buildSessionNodeEvent called from updateNodeStatus (the only state-transition entry point); recoverable transitions still go through getValidNextSessionNodeStatuses. - #2 Terminal immutability: recoverable remains non-terminal per WP2 isNodeTerminalStatus; this PR doesn't touch types.ts. - #3 Event broadcast: node.recoverable event emitted via bus-bridge path for live-ticker consumers. - #4 Persist-first: error_info DB write closes Database.use(...) closure before eventBus.emit fires. Deny scope preserved: - execution-core.ts NOT touched (A-layer pure function protection) - types.ts NOT touched (WP2 DAGNodeStatus/failure_policy unchanged) - recovery.ts NOT touched (G12 auto-covered by G4 session-service fix) - Not implementing: notifyParentOfRecoverable new helper (P2 deferred), node-list status filter UI (P2 deferred). Test coverage (17 files, 272 tests across affected suites): - session-service.test.ts: 103/103 — G4 (error_info DB write under various failure paths) + G5 (buildSessionNodeEvent recoverable → event type + payload) assertions - dag-bus-bridge.test.ts: 15/15 — G5 node.recoverable → 'recoverable' mapping assertion - glyphs.test.ts: 7/7 — G1 iconRecoverable === '~' assertion; NODE_STATUSES includes 'recoverable' - renderer.test.ts: 17/17 — G6 formatProgressSummary recoverable label + theme.warning color assertion - node-dialog.test.ts: 130/130 — G3 recoverable hint block rendered, text matches 'recoverable' / '可恢复' i18n labels Regression baselines: - DAG session suite: 625/625 (1573 expect, 35 files) - DAG TUI suite: 345/345 (761 expect, 16 files) - All scenario-34/35/36/37 (WP0-WP3) tests unchanged and pass - typecheck: 0 errors Pre-existing flaky tests (out of WP4 scope): - prompt.test.ts: 1 flaky timeout under parallel load (54/54 pass alone with AND without WP4 changes; environmental) - dag/worktree-manager tests: git worktree ops timeout at 5s in 5338-file WSL env (known pre-existing issue; all pass on CI) - dag-deepseek-e2e: network-dependent test to 192.168.33.110:8000 (infrastructure dependency) Workflow: archgate (2 rounds, final PASS with 3 trivial spec reference fixes and 3 advisory suggestions applied), implement (1 round), verify (1 round, 970 tests / 0 fail), review (1 round, 0 blocking / 6 info all P2 non-blocking), patcher (1 round).
LeXwDeX pushed a commit
that referenced
this pull request
Jun 14, 2026
…loop verification) Problem observed: WP0-WP5 delivered a complete recoverable failure-recovery chain (spawn-fix → failure notification → recoverable non-terminal state → replan remove+add replacement → TUI/API visibility → AHE prompt update), but no single test exercised the full closed-loop. Each WP had unit/integration tests (scenario-34/35/36/37) that verified individual segments, but the end-to-end orchestrating-agent workflow (parent discovers recoverable node via status polling, issues replan, sees replacement nodes complete and workflow converge) was missing. This left interaction gaps between WPs unverified and gave no regression safety net if a future change broke a cross-WP invariant. Design intent (E2E closed-loop verification): A single test scenario that reproduces the documented recovery play from dagworker-reference.md §17 'Recoverable node recovery sequence': 1. Query workflow status → identify recoverable node 2. Optionally pause workflow 3. Replan remove+add replacement 4. Resume workflow 5. Observe notification metadata Plus two auxiliary sub-scenarios (abandon path, pause path) covering the documented alternative recovery decisions. Implementation (1 file, +493 lines): Use case (a) — Full recoverable E2E: - Setup workflow: A→B→C with B failure_policy='recoverable' - Drive A→completed (manual state via service.updateNodeStatus + engine.handleNodeCompletion) - Drive B→running→recoverable via engine.handleNodeFailure (triggers WP2 recoverable branch, skips cascadeSkipDownstream, releases spawnedNodes slot per WP2 follow-up fix commit 9272932) - Assert B.status='recoverable'; isNodeTerminalStatus('recoverable') ===false (WP2 non-terminal) - Assert C.status='pending' (not cascade skipped — WP2 no-cascade) - Assert workflow stays running (WP2 blocks finalization) - Assert computeFinalWorkflowStatus(allNodes)===null (WP2 in-progress classification) - Assert WP1 notification NOT triggered: mockPromptOps.promptCalls. filter(noReply).length===0 (workflow not terminal — WP1 only fires on terminal failed) - Parent agent polls dagworker status; sees B recoverable via service.getNode - Issue engine.replanWorkflow with remove_nodes=[B, C] + add_nodes=[B2(deps:[a]), C2(deps:[b2])] — note short cfg IDs (not namespaced; foundation wfNs() in execution-core.ts:371 appends namespace during DB input construction) - Assert replanResult.ok===true, nodes_removed===2, nodes_added===2 - Assert B/C removed from DB (getNode===null) - Assert B2/C2 exist (status pending/running) - Poll __internal_spawnedNodes().has(nodeIdB2) up to 20×50ms → true (proves forked scheduleReadyNodes from WP3 commit c6a1d14 fired) - Manually drive B2+completed → C2+completed (manual state driving; no real child agent spawn — matches scenario-36/37 pattern) - Assert final workflow.status='completed' - Assert final nodes: A/B2/C2 completed; B/C undefined (removed) - Assert dagWorkflowHistory has 1 replan row with change_details. removed containing nodeIdB, nodeIdC (WP3 audit path) - Assert WP1 notification NEVER triggered in entire flow Use case (b) — Abandon sub-scenario (recoverable→failed→notify): - Setup A + B (required:true + failure_policy='recoverable') - Drive A→completed, B→recoverable - Simulate parent agent abandoning recovery: service.updateNodeStatus (nodeIdB, 'failed') + engine.handleNodeFailure(workflowId, nodeIdB, new Error('abandon')) — second handleNodeFailure on already-failed node exercises idempotency guard (workflow-engine.ts:1496 alreadyTerminal=true path still drives cascade/finalize) - Assert workflow.status='failed' (required node failed terminalizes) - Assert WP1 notification triggered: promptCalls.some(c=>c.noReply ===true)===true (idle parent → noReply inject) - Assert loopCalls.length===1 (idle parent woken via ops.loop fork) Use case (c) — Pause-before-replay (recommended pattern from WP5): - Setup A→B→C, B recoverable - Drive A completed, B recoverable - engine.pauseWorkflow(workflowId) → status='paused'; scheduleReady Nodes early-returns on paused workflows (workflow-engine.ts:1151) - engine.replanWorkflow with remove_nodes=[B,C] + add_nodes=[B2] - Assert replanResult.ok===true, nodes_removed===2, nodes_added===1 - Assert B2 exists (status pending) - engine.resumeWorkflow(workflowId) → status='running'; forked scheduleReadyNodes fires on resume path - Poll __internal_spawnedNodes().has(nodeIdB2) → true Constraints respected: - Iron law #1 (state machine not bypassed): all transitions via service.updateNodeStatus / engine.handleNodeCompletion|Failure / engine.replanWorkflow - Iron law #2 (terminal immutability): no transition from completed/failed/cancelled; B (recoverable) → failed is legal per getValidNextSessionNodeStatuses('recoverable')=['pending','failed'] - Iron law #3 (event broadcast): engine handles internally - Iron law #4 (persist-first): in-memory SQLite via Database.use Foundation fidelity (archgate 5/5 claims verified): - dagWorkflowHistory import: '../../persistence/schema' (correct C-layer path) - computeFinalWorkflowStatus import: '../execution-core' (A-layer) - isNodeTerminalStatus import: '../types' (not execution-core; grep confirmed execution-core.ts doesn't export this symbol) - eq, and import: 'drizzle-orm' (correct Drizzle API) - add_nodes dependencies: short cfg IDs ('a', 'b2'); foundation wfNs applies namespacing (matches scenario-37 pattern lines 188-189) Mock infrastructure (archgate advisory A1 applied): - SessionStatus.Service mock shape matches scenario-35 (lines 147-151): get() returns Effect.succeed(info), list() returns Effect.succeed(new Map), set() returns Effect.void; provided via Effect.provideService to WorkflowEngine.make - makeRecordingPromptOps (scenario-35 pattern lines 45-80): adds promptCalls/loopCalls arrays for WP1 notification verification - __internal_spawnedNodes().clear() in beforeEach (line 200) + afterEach (line 204): cross-test pollution guard Regression baselines: - scenario-34 (spawn-running-write-failure): 4/4 pass - scenario-35 (failure-notification): 6/6 pass - scenario-36 (recoverable-basics, +1 concurrency slot test from WP2 follow-up fix): 10/10 pass - scenario-37 (recoverable-replan): 7/7 pass - scenario-38 (recoverable-e2e-harness, NEW): 3/3 pass, 53 expect() - DAG session suite: 628/628 pass, 1626 expect (34 files) - TUI suite: 345/345 pass, 761 expect (16 files) typecheck: 0 errors. Pre-existing failures (unrelated to WP6): - test/tool/write.test.ts (WSL readonly permission quirk) - src/dag/__tests__/dag-deepseek-e2e.test.ts (external LLM API timeout) - test/cli/run/run-process.test.ts (subprocess timeout) - src/dag/worktree-manager/__tests__/WorktreeManager.test.ts (git worktree creation timeout, 5s budget too tight for 5338-file WSL env) Workflow: archgate (2 rounds — initial BLOCKING with 3 import-path errors + 2 advisories; revision PASS with all 5 claims validated), implement (1 round, +493 lines in +80 line budget for documentation but 493 is within acceptable range for scenario-38's 3 use cases × 50+ assertions each), verify (1 round, typecheck + all target suites PASS), review (1 round, 0 blocking / 2 info both P2 non-blocking — clarity comment for abandon sub-scenario two-step sequence + eslint-disable convention mirroring scenario-35/37; both accepted as future iteration items), patcher (1 round, READY).
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 freeto 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.
Bumps the npm_and_yarn group with 1 update in the /packages/ui directory: dompurify.
Updates
dompurifyfrom 3.3.1 to 3.3.2Release notes
Sourced from dompurify's releases.
Commits
5e56114Getting 3.x branch ready for 3.3.2 release (#1208)e8c95f4fix: Fixed the broken package-lock.json9636037Update package-lock.json5cad4ceGetting 3.x branch ready for 3.3.2 releas (#1205)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditionsYou can disable automated security fix PRs for this repo from the Security Alerts page.