feat(tasks): auto-work eligible flag on tasks (T-58) - #23
Merged
Conversation
Adds an autoWork: boolean opt-in flag to kanban tasks so the auto-work engine (T-64) only ever considers tasks the user explicitly marked eligible. Not every card should be touched by unattended automation — this ticket only builds the data model, API, and UI toggle; no scheduling logic. Stacked on feat/t57-task-dependencies (PR #22) since both tickets touch the same task protocol/DB/routes/UI files — this diff is the incremental change on top of T-57's dependsOn work, not a rebase onto main. - packages/protocol: Task.autoWork (always present, default false), CreateTaskRequest/UpdateTaskRequest.autoWork (optional). - apps/server/src/db/migrations/008-task-autowork.sql: ALTER TABLE tasks ADD COLUMN auto_work INTEGER NOT NULL DEFAULT 0, same pattern as 006-task-priority.sql. Indexed for the future T-64 engine query (WHERE auto_work = 1). - apps/server/src/db/tasks.ts: TaskRow/rowToTask carry auto_work through every read path (listTasks, getTask, findTaskByDisplayOrId). createTask/updateTask accept autoWork, persisted independently of the dependsOn set added by T-57. - apps/server/src/routes-tasks.ts: POST/PATCH /tasks validate autoWork is a boolean before hitting the DB layer, same shape as the existing dependsOn/priority checks. - apps/web: TaskCard shows a small Zap indicator next to the priority badge when autoWork is true. TaskModal gained an "Eligible for Auto Work" checkbox in the metadata grid, next to cwd. TaskDrawer.tsx is confirmed dead code (no imports anywhere, per T-57's findings) and was left untouched. Tests: apps/server/src/db/tasks.test.ts gained 6 cases covering default/explicit/toggle/untouched autoWork and independence from dependsOn on create+update+list+get round-trips.
jaesbit
force-pushed
the
feat/t58-autowork-eligible
branch
from
July 6, 2026 10:09
3f3af2b to
b5d06bd
Compare
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Why
Not every kanban task should be touched by auto-work. Explicit opt-in per task avoids accidental automation of sensitive or ambiguous cards.
Scope
autoWork: booleanadded to the task protocol (packages/protocol/src/index.ts), defaultfalse.008-task-autowork.sql:ALTER TABLE tasks ADD COLUMN auto_work INTEGER NOT NULL DEFAULT 0, indexed for the future T-64 engine query.GET /tasks,POST /tasks,PATCH /tasks/:idall read/writeautoWork.TaskModal's metadata grid;TaskCardshows a small Zap indicator whenautoWork === true, styled like the priority badge.This is task 2 of an 11-task "Auto Work" chain, stacked on
feat/t57-task-dependencies(PR #22) — not based onmain— since both tickets touch the same task protocol/DB/routes/UI files. This diff is only the incremental change on top of T-57'sdependsOnwork.Non-goals
The "engine only considers autoWork tasks" part of the ticket is explicitly deferred to T-64 (not built yet, not in scope here). This PR only ships the data model, API, and UI toggle — no scheduling logic.
Files changed
packages/protocol/src/index.tsapps/server/src/db/migrations/008-task-autowork.sql(new)apps/server/src/db/tasks.ts,apps/server/src/db/tasks.test.tsapps/server/src/routes-tasks.tsapps/web/src/components/tasks/TaskModal.tsx,apps/web/src/components/tasks/TaskCard.tsxTaskDrawer.tsx(listed in the ticket's surface area) is confirmed dead code — not imported anywhere in the app — so it was left untouched, matching T-57's precedent.Validation
bun run --filter '@omp-deck/server' typecheck— cleanbun run --filter '@omp-deck/web' typecheck— cleancd apps/server && bun test— 246/246 pass (6 new autoWork cases; includes T-57's 11 dependency cases still passing)cd apps/web && bun test— 149/149 passbun run --filter '@omp-deck/web' build— succeeds (pre-existing >500kB chunk warning, unrelated)Acceptance
falseon create; must be explicitly opted in.