kurihada/ai-workflow-skill
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add spec-aware orch tasks and verification gates

Browse Source
This commit is contained in:
kurihada
2026-03-23 14:05:10 +08:00
parent 4d8c90eb26
commit 9f9b66330c
22 changed files with 1696 additions and 55 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture.md
+5 -2
View File
@@ -8,6 +8,7 @@ The design target is a local, file-portable agent coordination stack:
- `inbox`: durable communication bus
- `orch`: task graph and scheduling control plane
- spec-aware tasks and verification gates owned by `orch`
- worktree-backed task execution for code-writing workers
- optional user-facing council review workflow on top of `orch`
- shared SQLite database file
@@ -25,7 +26,7 @@ If `inbox` is reduced to pure chat storage, the scheduler must reconstruct state
## Role Model
- `user`: talks only to the leader
- `leader`: owns the overall goal, task graph, acceptance criteria, and final integration
- `leader`: owns the overall goal, task graph, task specs, acceptance criteria, verification policy, and final integration
- `worker`: executes one assigned task at a time and reports through `inbox`
- `inbox`: durable thread/message/lease/artifact store
- `orch`: run/task/dependency/dispatch state machine built on top of `inbox`
@@ -45,7 +46,7 @@ If `inbox` is reduced to pure chat storage, the scheduler must reconstruct state
Both CLIs should point at the same SQLite file.
- `inbox` owns communication tables such as threads, messages, leases, and artifacts.
- `orch` owns scheduling tables such as runs, tasks, dependencies, and attempts.
- `orch` owns scheduling tables such as runs, tasks, dependencies, attempts, task specs, and verification check results.
- both layers append to a shared event stream for blocking waits
- `orch dispatch` creates or updates `inbox` threads.
- `orch reconcile` reads `inbox` state and updates task state.
@@ -135,9 +136,11 @@ If packaging later favors a single binary, the same model can be exposed as comm
- runs
- task graph and dependencies
- task spec snapshots and task-level policy metadata
- ready queue calculation
- dispatch decisions
- task-attempt worktree allocation
- verification gates and check-result aggregation
- blocked queue review for the leader
- retries, reassignment, and cancellation
- mapping task attempts to inbox threads