You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Granary now supports an optional review gate in the task and project lifecycle. When enabled, completed work transitions to `in_review` instead of going straight to `done`/`completed`, giving a reviewer (human or agent) the chance to approve or reject it before it's finalized.
4
+
5
+
**Two scopes:**
6
+
7
+
-**`task` mode** — `granary work done` moves the task to `in_review` and emits a `task.review` event. A reviewer approves or rejects individual tasks.
8
+
-**`project` mode** — Tasks still complete normally, but when all tasks are done, the project enters `in_review` instead of `completed`. Reviewers approve the project as a whole, or reject it by creating follow-up tasks and reopening the project.
-`granary review <id> approve ["comment"]` — approves and completes the entity
14
+
-`granary review <id> reject "feedback"` — rejects with feedback; tasks return to `todo`, projects reopen to `active` with draft tasks promoted to `todo`
15
+
16
+
Review comments use a new `review` comment kind, and review events (`task.review`, `project.review`) are emitted so downstream agents or integrations can react.
17
+
18
+
### Review mode configuration
19
+
20
+
Review mode is stored in the workspace database (`config` table) under the key `workflow.review_mode`. Enable it with:
21
+
22
+
```
23
+
granary config set workflow.review_mode task # or 'project'
The `trg_project_auto_complete` trigger is now config-aware — when `workflow.review_mode` is set to `project`, it transitions the project to `in_review` instead of `completed`. New triggers emit `task.review` and `project.review` events on status transitions.
Copy file name to clipboardExpand all lines: AGENTS.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,9 @@
1
1
# Agent Instructions
2
2
3
+
## Formatting
4
+
5
+
After implementation is complete, use `cargo fmt` to format files. Always run `cargo clippy` before committing to ensure there are no warnings or errors.
6
+
3
7
## SQL Migrations
4
8
5
9
- Always create migrations via SQLx CLI from the repo root:
After implementation is complete, use `cargo fmt` to format files.
1
+
# Agent Instructions
2
2
3
-
IMPORTANT: when user requests to "use granary", run `granary` command before performing any other task.
3
+
## Formatting
4
+
5
+
After implementation is complete, use `cargo fmt` to format files. Always run `cargo clippy` before committing to ensure there are no warnings or errors.
6
+
7
+
## SQL Migrations
4
8
5
-
## Iced GUI Development
9
+
- Always create migrations via SQLx CLI from the repo root:
10
+
-`sqlx migrate add <name>`
11
+
- Do not hand-write timestamp/version prefixes in migration filenames.
12
+
- If you hit a duplicate migration version error, regenerate one migration with `sqlx migrate add <name>` and move the SQL into the newly generated file.
6
13
7
-
The `crates/silo/` crate uses the Iced GUI library. When working on files in this crate, the `.claude/skills/iced-development.md` skill is automatically applied. It contains best practices for:
0 commit comments