build(deps): bump minimatch from 10.0.3 to 10.2.3 in /packages/opencode in the npm_and_yarn group across 1 directory - #3
Closed
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps the npm_and_yarn group with 1 update in the /packages/opencode directory: [minimatch](https://github.com/isaacs/minimatch). Updates `minimatch` from 10.0.3 to 10.2.3 - [Changelog](https://github.com/isaacs/minimatch/blob/main/changelog.md) - [Commits](isaacs/minimatch@v10.0.3...v10.2.3) --- updated-dependencies: - dependency-name: minimatch dependency-version: 10.2.3 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/opencode/npm_and_yarn-96a93d4c45
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
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 7, 2026
…ly & navigation WP4 workspace components (topological node tree, progress bar, sidebar history/filter, ascii-dag view, live ticker, node dialog, status helpers) with unit tests (47 pass). Fixes: - dag/layer.ts: self-contained dagQueryLayer.pipe(provideMerge(sharedEventBusLayer)) exposing both tags; resolves SharedEventBusTag leak that caused black screen. - server.ts: wire DagBridgeLayer via provide([DAGLayer, Bus.layer]) so the platform Bus singleton is shared (DAG law #3, single EventBus instance). - dag-console/console-route: goBack now carries returnRoute params + sessionID fallback; add ESC keybinding (was a label only). - dag-workflow/console-route: goToSessionTab carries params + fallback; remove dead isLoading branch. - renderer: tree connector uses real last-sibling detection. - ascii-dag: nodeStatusIcon drops unused color field.
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
…an (Iron Law #3) Iron Law #3 requires that every significant state change be broadcast via the event bus. Replan previously wrote the durable audit row to dag_workflow_history but did NOT emit a corresponding event, which left real-time subscribers (TUI, external listeners) blind to replan operations. This commit closes that gap. Changes: 1. WorkflowEvent union (state-machine/types.ts L233-244) — added new variant: { type: 'workflow.replanned'; workflow_id; chat_session_id; patch_summary: {added, removed, updated, final_total}; timestamp } 2. emitWorkflowReplannedEvent helper (session-service.ts L157-170) — exported module-level helper that checks _eventBus and emits the typed event. Pattern matches existing emitSessionWorkflowEvent usage at L409 and L600. 3. Call site in replanWorkflow (workflow-engine.ts L745-750) — emits after atomic apply succeeds + spawnedNodes cleanup completes, before the final return. This placement guarantees the event only fires on fully-committed replan success (Iron Law #4 persist-first discipline respected). 4. Bridge layer exhaustive switch fix (dag-bus-bridge.ts L224) — TypeScript exhaustive switch on WorkflowEvent forced a new case for the variant. Added 'case workflow.replanned: return null' mirroring the existing paused/resumed/archived pattern. Bridge does not forward to TUI (returns null) — deferred to follow-up WP for TUI real-time updates. The variant flows through the event bus so external subscribers can react. Event shape rationale: - workflow_id + chat_session_id together uniquely identify the session scope (matches existing workflow.created / workflow.completed events) - patch_summary carries the operational intent (added/removed/updated counts + final_total) for quick rendering without DB round-trip - timestamp uses the same Date semantics as other WorkflowEvent variants (constructed at emit time, not DB row created_at) Verification: typecheck 0 errors; 138/138 session tests pass (unchanged — no test file modifications per scope.forbid).
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
Closes B3 from global DAG review report: process restart no longer
leaves orphaned running workflows stuck in zombie state. Two
components delivered in single WP:
## Phase A: Startup orphan recovery scan
New module `src/dag/session/recovery.ts` (85 lines) exports pure
Effect function `recoverOrphanedWorkflows(service)` that:
1. Lists all workflows via `service.listAllWorkflows()`
2. Filters to `status === 'running'` AND `WorkflowEngine.get(id) === undefined`
(i.e., in DB as running but no engine in memory → orphan from prior
shutdown)
3. Per orphan:
- Marks workflow `status='failed'` (legal transition: running→failed)
- Creates violation `type='process_orphan' severity='critical'` for
audit trail
- Transitions child nodes: running→failed, queued→skipped,
pending→skipped (all legal via getValidNextSession*validators)
4. Returns `{ scanned, marked }` summary
## Phase B: /dag-resume slash command
New template `src/command/template/dag-resume.txt` with LLM prompt
that clones a failed workflow's stored config into a fresh new
workflow via existing `dagworker start` tool:
- Reads source workflow config via `dagworker { action: "status" }`
- Creates new workflow via `dagworker { action: "start" }` with the
original config JSON (no namespace, no workflow ID — dagworker start
tool handles all materialization with new UUID + fresh nodes)
- Reports both old (failed+history) and new (fresh) workflow IDs
Registered as `Default.DAG_RESUME = "dag-resume"` in command/index.ts
following the existing dag-ctl pattern.
## Layer composition (archgate PASS)
**Architecturally critical**: Recovery layer is EMBEDDED inside the
existing `dagQueryLayer` Effect.gen body (dag/layer.ts:43-46), NOT
added as a sibling or in CoreLayer. This was a BLOCKING requirement
from archgate validation:
- CoreLayer (effect/app-runtime.ts) is process-wide scope; DAG is
HTTP-server-scoped subsystem → recovery layer must live in DAG
layer, not CoreLayer
- CLI/TUI modes don't run recovery scan (DAGLayer.defaultLayer isn't
imported in those contexts)
- Recovery runs AFTER `setEventBus(bus)` and AFTER
`DAGSessionService.make` but BEFORE `return new DAGQuery(...)` —
ensuring event broadcasting + service availability before recovery
executes
- Single DAGSessionService.make instance (no duplicate)
- SharedEventBusTag dependency explicit — no silent Iron Law #3
degradation
```ts
const dagQueryLayer = Layer.effect(
DAGQueryTag,
Effect.gen(function* () {
const bus = yield* SharedEventBusTag // L37 explicit
setEventBus(bus) // L39
const sessionService = yield* DAGSessionService.make // L40
yield* recoverOrphanedWorkflows(sessionService).pipe( // L43
Effect.tapError((err) => Effect.logWarning(
`[DAG recovery] top-level failure (non-fatal): ${err}`
)),
Effect.ignore
)
return new DAGQuery(sessionService) // L47
}),
)
```
## Iron Law compliance
All four iron laws satisfied at service boundary (not caller):
1. **State machine integrity**: All transitions use service methods
(`updateWorkflowStatus` / `updateNodeStatus`) which validate via
`getValidNextSession*` tables:
- workflow running→failed (session-service.ts:55)
- node running→failed (L78)
- node queued→skipped (L76)
- node pending→skipped (L74)
Never queued→failed (illegal — would have required direct DB bypass)
2. **Terminal irreversible**: Recovery only transitions to terminal
states; never reopens terminals. Scans SELECT `status='running'`
so terminals are ignored.
3. **Events broadcast**: Service methods emit via `_eventBus` after
persist. Event bus initialized BEFORE recovery runs (L37/L39/L43).
4. **Persist-first**: Service methods write DB before emitting
(session-service.ts:422-426 vs 430-436 for workflows; 614-618 vs
621-627 for nodes).
## Tests: 4 scenarios
New file `src/dag/session/__tests__/recovery.test.ts` (224 lines):
- **no-orphans**: Empty DB scan returns {scanned:0, marked:0}
- **one-orphan**: One running workflow with 3 nodes (running, queued,
pending), no engine registered → marked=1, workflow failed,
violation created, nodes: running→failed, queued→skipped,
pending→skipped
- **live-not-orphan**: One running workflow WITH registered engine →
left alone (not an orphan; legitimate live workflow). Test
cleanup cancels workflow to `completed` before `unregisterEngine`
to avoid leaking as orphan into subsequent test.
- **partial-progress**: One orphaned workflow with [completed,
running, pending] nodes → completed preserved (no-op),
running→failed, pending→skipped
Bootstrap pattern: `Flag.OPENCODE_DB = ":memory:"` +
`Database.Client.reset()` in beforeAll/afterAll — identical to
existing scenario-22 test infrastructure.
## Schema extension
Added `'process_orphan'` to `DAG_VIOLATION_TYPES` const array
(`src/dag/session/types.ts`). The derived `DAGViolationType` union
auto-includes the new value via `(typeof DAG_VIOLATION_TYPES)[number]`.
Cascade consequence (typecheck required): added `process_orphan` to
`VIOLATION_TYPE_LABEL` Record in
`src/cli/cmd/tui/feature-plugins/dag-workflow/i18n.ts` (en + zh
strings) — purely additive, mechanical, no logic change.
## Verification
- typecheck: 0 errors (tsgo --noEmit exit 0)
- recovery.test.ts: **4/4 pass** (17 expect() calls, 15.88s)
- session baseline: **179/0 pass** (175 original + 4 new)
- DAG broader (non-worktree): **545 pass**, 17 PRE-EXISTING
worktree-manager failures unrelated to this changeset (5s git
worktree timeout in 5291-file repo environment)
## Design rationale
**Why Path C (mark failed + /dag-resume manual command) over other
recovery paths?**
- Path A alone (mark failed, no recovery command): honest but forces
user to manually rebuild lost progress. Sub-optimal UX.
- Path B (auto-rehydrate from DB): partial state is impossible —
promptOps (LLM agent connection), child opencode sessions, and
in-memory spawnedNodes/concurrencyRegistry are all lost at process
restart. Auto-rehydration would mask real losses under false
reassurance.
- Path C (honest + manual /dag-resume): user explicitly chooses to
clone config into fresh workflow, preserving history of the failed
run while starting fresh. The old workflow becomes read-only
audit trail (terminal states irreversible per Iron Law #2).
**Why embedded in dagQueryLayer rather than separate recovery layer?**
Effect Layer.mergeAll does not cross-wire siblings, so a sibling
crashRecoveryLayer would create its own DAGSessionService.make with
`_eventBus = undefined` (silent Iron Law #3 degradation). Embedding
inside dagQueryLayer ensures single instance + explicit bus
dependency. This was the BLOCKING finding from archgate v1 spec.
**Why no effect on CoreLayer / app-runtime.ts?**
CoreLayer is process-wide composition consumed by CLI/TUI/HTTP server.
DAG subsystem is scoped to HTTP server via DAGLayer.defaultLayer
import (`server.ts:60` → `server.ts:245`). Adding crash recovery to
CoreLayer would force SQLite scans against `dagWorkflows` on every
opencode process (including CLI invocations where DAG is unused) —
unacceptable cross-cutting and boundary violation.
## Out of scope (deferred to later WPs)
- B4 WorktreeManager integration (separate WP for runtime worktree
isolation of parallel DAG nodes)
- Retiring state-machine/scheduler/group-manager suite (separate WP;
~6K LOC dead code in non-runtime path)
- I1 executeReadyNode implementation (still Effect.die, out of scope
for crash recovery)
## Notes
- `oc` (root shell script) intentionally not in this commit — that's
user-managed version upgrade tool, committed separately
- Test cleanup uses `service.updateWorkflowStatus(wid, 'completed')`
before `unregisterEngine` in `live-not-orphan` — necessary to
prevent orphan leakage into subsequent tests since they share a
single in-memory DB session.
- `Effect.runSync` used in recovery.test.ts (permitted in tests)
- 0 `as any`, 0 `Effect.runSync`, 0 `try`/`catch` in production
recovery.tsLeXwDeX pushed a commit
that referenced
this pull request
Jun 7, 2026
Closes B4 WP1 from global review: integrate WorktreeManager into DAG
spawn path so parallel nodes can work in isolated git worktrees
instead of sharing the parent session's CWD. When a DAG node's
config has `worker_config.use_worktree: true`, its opencode sub-agent
session runs in a dedicated worktree directory.
## What it does
When `spawnReadyNode` spawns a parallel DAG node:
- Reads `node.config.worker_config.use_worktree === true` (opt-in flag)
- If true AND worktreeManager available:
- Generates deterministic branch: `dag-<workflowId>-<node-config-id>`
- Calls `wtManager.create(node.node_id, {basePath, branch})`
- Captures worktreeInfo.path
- Passes `directory: worktreeInfo.path` to `sessions.create(...)`
- Wraps cleanup in `Effect.ensuring` (fires on any exit path:
success, failure, fiber cancel)
- If false OR worktreeManager unavailable: falls back to parent CWD
(current default behavior preserved)
## Why opt-in
- Backward compatible: existing users with non-isolated DAG workflows
keep working without any config change
- Worktree creation has overhead (git clone-ish cost + disk usage) —
only pay it when needed (e.g., parallel nodes writing to same files)
- User explicitly opts in per-node via `worker_config.use_worktree: true`
## Scope (4 files)
### session/session.ts (+7 lines)
- Added `directory?: string` to `Interface.create` input shape (line
~471-483) — the 9th optional field in an all-optional input
- In `Session.create` impl (L701-727): threads `sessionDir = input.directory
?? ctx.directory` through to BOTH `directory: sessionDir` AND
`path: sessionPath(ctx.worktree, sessionDir)` (archgate explicitly
flagged both fields must use sessionDir, not just one)
Backward compatible: all existing callers omit `directory` (no caller
passing it before this commit), continue to get `ctx.directory` as
before.
### dag/layer.ts (+19 lines)
- Added `WorktreeManagerTag` via `Context.Service<Tag, IWorktreeManager>()`
(tag string: `"@opencode/DAGWorktreeManager"`)
- Added `worktreeManagerLayer = Layer.effect(WorktreeManagerTag,
Effect.gen(function* () { const bus = yield* SharedEventBusTag;
return new WorktreeManager(bus) }))` — no persister (in-memory
Map OK for DAG node lifetime per §0.3 architecture rule)
- Composed into `defaultLayer`: `dagQueryLayer.pipe(Layer.provideMerge(
sharedEventBusLayer), Layer.provideMerge(worktreeManagerLayer))`
Order matters: `sharedEventBusLayer` provided first so
`worktreeManagerLayer` can `yield* SharedEventBusTag`.
### dag/session/workflow-engine.ts (+57 lines)
- Restructured `spawnReadyNode` from `Effect.gen` arrow-inlined form to
a closure form so `Effect.ensuring` can wrap the body while
capturing `worktreeCleanup` callback across Effect fiber lifecycle.
- Step 2.5 inserted (between agent resolve and sessions.create):
- Type guard: `(node.config.worker_config as {use_worktree?:
boolean} | undefined)?.use_worktree === true` — NO `as any`
(per §0.4)
- Defensive yield for WorktreeManagerTag wraps in Effect.gen +
catchCause fallback (handles case where layer composition
differs from default)
- `wtManager.create(node.node_id, {basePath: process.cwd(),
branch: \`dag-${workflowId}-${node.config.id}\`})`
- Note: basePath falls back to process.cwd() because ctx.worktree
is not in spawnReadyNode scope (InstanceState is Session-layer
concept). Documented limitation in this commit message.
- If worktree create fails: mark node 'failed' + return early
(don't continue without worktree; don't crash)
- sessions.create call uses spread: `...(worktreePath ? { directory:
worktreePath } : {})`
- Effect.ensuring at end of body:
```
Effect.ensuring(Effect.sync(() => {
if (worktreeCleanup) {
worktreeCleanup().catch(err =>
console.warn(`[DAG] worktree cleanup failed: ${err}`)
)
}
}))
```
- spawnReadyNode return type preserved as `Effect.Effect<void, never,
never>` — the cleanup Effect.ensuring uses Effect.catchCause to
swallow errors, maintaining the never type invariant.
### dag/session/__tests__/workflow-engine.test.ts (+112 lines)
Three new tests appended (not modifying existing 37):
**Test A: opt-out flow** — `worker_config` has no use_worktree flag.
Asserts Session.create NOT called with directory; WorktreeManager.create
NOT called.
**Test B: opt-in flow** — `worker_config.use_worktree: true`. Asserts:
- WorktreeManager.create called with `branch === \`dag-<wf>-<cfg-id>\``
- Session.create called with `directory === worktreePath` where
worktreePath = the path returned by wtManager.create
- Cleanup callback registered (would fire post-prompt)
**Test C: cleanup fires on any exit path** — Use-worktree enabled +
prompt fails. Asserts cleanup callback still fires via helper
`simulateSpawn` that models both `Effect.ensuring` (try/finally) AND
`Effect.catchCause` (outer try/catch swallow). This verifies the
production code pattern where cleanup fires regardless of exit path.
## Acceptance
- typecheck: 0 errors (tsgo --noEmit exit 0)
- `workflow-engine.test.ts`: **40/40 pass** (37 original + 3 new)
- session baseline: **182/182 pass** (179 original + 3 new)
- DAG broader (non-worktree): **547 pass** / 17 PRE-EXISTING
worktree-manager.test.ts failures (5s git worktree add timeouts —
unrelated to this changeset, infrastructure limitation)
- Session.create backward compatible: all existing callers work
unchanged (directory field optional)
- spawnReadyNode reads `worker_config.use_worktree` with type guard
(zero `as any` in new code)
- `Effect.ensuring` cleanup fires on ALL exit paths (success, failure,
fiber cancel)
- Branch name deterministic `dag-<workflowId>-<node-config-id>` — unique
per (workflow, node) pair; git branch name compliant
([a-zA-Z0-9._-])
## Iron Law compliance
All four iron laws verified against production code:
1. **State machine integrity** — worktree create/cleanup does NOT
touch node state machine; node state transitions unchanged; all
via `sessionService.updateNodeStatus()` which validates via
`getValidNextSessionNodeStatuses`.
2. **Terminal irreversible** — worktree lifecycle (memory Map in
WorktreeManager) is independent from node state machine. Node
terminals not affected.
3. **Events broadcast** — `WorktreeManager` constructor takes
`SharedEventBus` (from SharedEventBusTag), emits `worktree.created`
/ `worktree.deleted` events into the shared bus (Iron Law #3
broadcast).
4. **Persist-first** — §0.3 architecture rule allows "no persister
when in-memory is fine". For DAG node lifetime (minutes), in-memory
tracking is adequate. WorktreeManager.ts:78 silent-skips when
persister is absent.
## Architecture decisions
### Why separate WorktreeManagerTag (not just inline WorktreeManager
in spawnReadyNode)?
- Follows established Effect DI pattern in dag/layer.ts (DAGQueryTag,
SharedEventBusTag, DAGSessionService all go through layer composition)
- Single WorktreeManager instance per process (Effect memoizes by
tag) — cheaper than instantiating per node
- Testable: tests can provide mock WorktreeManager via Effect.provide
on WorktreeManagerTag
### Why `basePath: process.cwd()` instead of `ctx.worktree`?
`ctx` is `InstanceContext` (Session-layer concept from
project/bootstrap.ts). spawnReadyNode lives in DAG layer which is
downstream from Session layer. ctx.worktree is NOT reachable from
DAG scope without violating layer direction.
Fallback: `process.cwd()` — the directory from which opencode was
launched. For most single-repo setups this is equivalent to git
root. For multi-repo setups or nested project invocations, this may
create worktrees in unexpected locations. Documented known limitation.
Fix would require exposing `ctx` through a Session-layer Effect tag
and injecting it into DAG layer — out of scope for this WP. Tracked
as future improvement.
### Why no persister for WorktreeManager?
- DAG node lifetime ≈ minutes (single workflow run)
- In-memory Map is adequate for this lifetime
- Persister adds complexity (filesystem persistence, reload logic)
- §0.3 architecture rule explicitly allows this
- If persistence is later needed (crash recovery of in-flight
worktrees), it's a follow-up WP
### Why `as {use_worktree?: boolean}` instead of `as any`?
§0.4 architecture rule forbids `as any`. The worker_config is
deliberately `Record<string, unknown>` in DAGNodeConfig —
`unknown` is the intended extension point for worker-specific
settings. Type guard with proper narrow type `(as {use_worktree?:
boolean} | undefined)` is idiomatic Effect/TypeScript, passes
strict mode, and respects §0.4.
## Out of scope (deferred to later WPs — B4 WP2)
- Retiring state-machine/scheduler/group-manager dead-code suite
(~6K LOC, 166 tests not in runtime path) — B4 WP2
- Updating README / AGENTS.md marketing claims about Worktree
(currently they overstate isolation availability) — B4 WP2
- Persister integration for WorktreeManager (if ever needed)
- Changes to state-machine/scheduler/group-manager (B4 WP2 deletes
them)
- Exposing ctx.worktree to DAG layer for more accurate basePath
## Notes
- `oc` (root shell script) intentionally not touched — user-managed
version tool.
- WorktreeManagerTag always instantiated per process (even when no DAG
nodes use it) — negligible cost: just an empty Map + EventBus ref.
- The defensive `Effect.gen + catchCause` wrapper around
`yield* WorktreeManagerTag` is intentional: makes spawnReadyNode
safe to call from ANY Effect environment, not just the default
runtime where WorktreeManagerTag is guaranteed. Graceful degradation
when service isn't provided (custom layer composition, test env).
## Verification log
- typecheck: 0 errors (tsgo --noEmit exit 0)
- bun test src/dag/session/__tests__/workflow-engine.test.ts: 40/40
- bun test src/dag/session: 182/182
- bun test src/dag: 547 pass + 17 PRE-EXISTING worktree timeouts +
6 skip (state-machine pre-existing skips)LeXwDeX pushed a commit
that referenced
this pull request
Jun 7, 2026
…points Adds JSDoc-style documentation comments at 4 key DAG entry points to serve future maintainers during a product review. Comment-only — zero behavior changes, zero type changes. ## File 1: dag/session/types.ts (+28 lines) Documents DAGNodeConfig/DAGConfig interfaces as the canonical single source of truth for DAG configuration shape. Calls out: - worker_type is free-form string routed via Agent.Service.get() — built-in agents (build/plan/general/explore/scout) vs user-defined custom agents (implement/verify/review/etc. used in docs) - dependencies are bare cfg.id values, NOT namespaced with workflowId:: (namespacing happens at materialization time) - required=false means node skip/failure doesn't cause workflow-level failure (maybeFinalizeWorkflow semantics) - worker_config is opaque bag with known keys: prompt, agent, use_worktree (B4-WP1 isolation) ## File 2: dag/session/workflow-engine.ts (+23 lines) Adds 'Dual-Path Architecture' block at top explaining: - Session path (this file) is the current production runtime - Core path (state-machine/scheduler/group-manager) is a deliberately isolated capability reservoir, NOT dead code — reserved for shadow execution / dry-run / richer transitions - Anti-pattern warning: don't call NodeStateMachine/Scheduler/ GroupManager from here; that breaks the dual-path contract documented in ARCHITECTURE.md:281-282 (decision D-PLAN) ## File 3: dag/layer.ts (+20 lines) Documents the 3-layer composition of defaultLayer: 1. sharedEventBusLayer — singleton EventBus (Iron Law #3) 2. worktreeManagerLayer — opt-in per-node worktree (B4-WP1, no persister per §0.3 — in-memory Map is adequate for DAG node lifetime) 3. dagQueryLayer — includes B3 crash recovery scan on init Explains why recovery lives here (HTTP-server scoped) and not in effect/app-runtime.ts CoreLayer (process-wide): DAG is scoped to HTTP server, not to CLI run mode. ## File 4: tool/dagworker.ts (+24 lines) Documents worker_type resolution contract: - Lists built-in agents (always available): build, plan, general, explore, scout - Warns that many documented examples use implement/verify/review which are USER-DEFINED custom agents (must be configured via opencode.json/opencode.jsonc agents field), NOT built-in - Warns that if LLM constructs DAG using worker_type='implement' without user configuring custom 'implement' agent, the spawn will fail at runtime with agent.get() error - Recommends verifying worker_type is built-in OR custom-before calling dagworker start ## Acceptance - typecheck: 0 errors (comments don't affect types) - session tests: 182 pass / 0 fail (no regression) - DAG broader tests: not affected (comment-only) ## Notes - Pre-existing oc file change in working tree is NOT included in this commit (user's own version upgrade tool, separate PR) - All comments in English (consistent with codebase style) - Follows AGENTS.md code-style guidance (no prose in code, only at module-level orientation and non-obvious constraint points)
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
…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 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).
LeXwDeX pushed a commit
that referenced
this pull request
Jun 23, 2026
… JSX) Gradual MVC refactor, Step 3b: View extraction (part 1 of 2). Extract AGENT popup overlay JSX from console-route.tsx into views/agent-popup-view.tsx — pure View component, props-driven (node/conversation/toolCounts accessors + i18n + theme colors + onEnterSubSession callback). No business logic, no SDK calls, no state ownership. Preserves layout exactly (top metadata / scrollable conversation summary / footer link) and OpenTUI iron law #3 (overlay modeStack push stays in controller). console-route.tsx: inlined ~90 lines of AGENT popup JSX replaced with a single <AgentPopupView .../> call. Unblocks console-route toward the <150-line composition-only target. console-route.test.ts: stickyScroll layout-guard test (source-grep) updated to read console-route.tsx + views/agent-popup-view.tsx combined — the stickyScroll={false} fix moved with the popup. Test intent (regression guard) preserved; only the file path assumption updated to follow the code. Verify: typecheck 0 errors; 279 pass / 0 fail.
LeXwDeX pushed a commit
that referenced
this pull request
Jun 24, 2026
… guide - Remove 'Default branch: stable' and related iron laws (#3, #4) - Add comprehensive DAG TUI development guide (architecture, view/controller/data layer conventions, common pitfalls) - Remove notes/ section and archived note files - Untrack PERFORMANCE-AUDIT.md/PLAN.md (local-only, gitignored) - Ignore .claude/ and .artifacts/ build output
LeXwDeX pushed a commit
that referenced
this pull request
Jun 25, 2026
Add rolling retention: each project keeps the N most recent terminal workflows (config.dag.retain_workflows, default 20). On workflow terminal state, enforceRetention queries all terminal workflows via a single SQL JOIN (dag_workflow + session), groups by project_id in memory, and cascade-deletes the oldest excess entries. Cascade delete (deleteWorkflowCascade) removes in dependency-safe order: DAG tables in one transaction first, then child sessions via Session.Service.remove. Idempotent — deleting non-existent rows is a no-op. Bug fix: maybeFinalizeWorkflow previously deleted ALL child sessions on terminal state (the 'best-effort child session cleanup' block), causing 'Session not found' when users revisited completed nodes. That aggressive cleanup is replaced by enforceRetention, which only removes child sessions belonging to retention-overflow workflows. Multi-model adversarial review fixes (opus4.8/gpt5.5/qwen3.7-max): - P1: LEFT JOIN → INNER JOIN so orphan workflows (session deleted) don't collapse into a shared pseudo-project bucket and get cross-project-deleted - P1: emit dag.workflow.deleted event on cascade delete (iron law #3) so TUI useWorkflowList refreshes and drops ghost rows - P2: cancelWorkflow now triggers enforceRetention (was bypassing it) - P2: reorder cascade — DAG tables deleted before child sessions so a mid-cascade failure leaves harmless orphan sessions, not dangling DAG rows pointing at gone sessions - P2: stable sort tiebreaker (workflow_id) for null completed_at rows
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/opencode directory: minimatch.
Updates
minimatchfrom 10.0.3 to 10.2.3Changelog
Sourced from minimatch's changelog.
... (truncated)
Commits
ea9484010.2.30873fbaupdate depscecaad1more extglob coalescing for performance11d0df6limit nested extglob recursion, flatten extglobsc3448c4update assertValidPattern param type to unknown from any0bf499alimit recursion for **, improve perf considerably9f15c58update depsf42b23910.2.2fa2133bupdate depsb9d0153ci: update action workflowsDependabot 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.