Automation

Hamstik Automation lets Organization owners/administrators and effective Project administrators automate repetitive Work Item updates. A rule combines a bounded trigger, an optional typed condition, and an ordered list of authorized actions. Rules are versioned and newly created rules start disabled, so nothing runs until an administrator enables it. Automation introduces no new plan gate.

Permissions

A rule belongs to one Organization and either one Project or an explicit set of Projects.
Organization owner/admin authority is required to manage a multi-Project rule. Effective Project admin authority is sufficient for a single-Project rule.
Every target still requires current Project access, revalidated when the rule runs. Automation never uses platform privileges and never retains a departed owner’s access.
A new rule is owned by its creator. To transfer ownership, a manager requests the transfer to an eligible member; the current owner remains in effect until that member accepts using their own current rule-management authority. A manager can cancel an unaccepted request. A queued run whose owner has lost authority is cancelled with a reason and makes no changes.

Triggers

Event triggers fire from Work Item changes:

Trigger	Fires when
Work Item created	A Work Item is created.
Status changed	A Work Item status changes.
Assignee changed	A Work Item assignee changes.
Priority changed	A Work Item priority changes.
Labels changed	A label is added to or removed from a Work Item.
Child status changed	A child’s status changes and the target is its immediate parent in the same Project.

The scheduled trigger runs daily at 00:00 UTC with a configured inactivity threshold of 1–365 whole days. Staleness is elapsed time since the latest non-automation Work Item field or comment change; automation housekeeping does not reset that clock. New or re-enabled schedules start at the next daily occurrence, with no historical catch-up.

Conditions

Conditions are a typed conjunction/disjunction of supported Work Item query predicates. For a child-status trigger you may also require that all eligible immediate children are Done. An empty child set does not satisfy all-children-Done, and if execution authority cannot inspect every immediate child the predicate is unknown and the action does not run. Conditions never contain arbitrary scripts, network calls, custom expressions, or arbitrary graph traversal.

Actions

Actions execute in declared order and apply to the triggering item or, for eligible triggers, its immediate parent in the same Project:

transition using existing transition validation;
assign an eligible member or clear the assignment;
set priority;
set or clear the due date, either as a fixed UTC instant or N whole days after the trigger occurrence (N = 0–365);
add or remove an existing Project label;
add a literal Markdown comment.

Comment bodies are literal text under the existing content limits — there are no executable templates. Scheduled rules act on each matching Work Item.

Execution and run history

Triggers are captured durably and evaluated against current authorized state. All actions for one rule/item apply atomically: a validation or authorization failure applies none of them. Rules for an item run serially in stable creation-time/ID order. Notifications follow the same rules as a normal mutation, and retries never duplicate a successful effect, comment, or history entry.

Every outcome writes one explainable run with a status of success, no_match, suppressed, cancelled, or failed, plus the rule/version, the trigger snapshot, the evaluated revision, and the before/after proposed values. Run summaries are retained for 90 days and never copy secrets or full Work Item bodies.

A rule cannot reenter its own lineage, and a chain is capped at 10 rule executions; suppressed loops remain visible. Editing a rule does not silently change a queued run: disabled/deleted rules and stale queued versions are cancelled with a reason.

Preview and guardrails

Dry-run preview performs authorized evaluation and returns matches, before/after proposed values, and validation errors without mutations, comments, notifications, or executable jobs. Preview requires the same rule-management authority as managing the rule, and it never exposes Work Items in Projects the caller cannot access. Preview is informative, not a reservation; execution revalidates.

Initial guardrails:

500 rules per Organization, of which at most 100 may be enabled;
10 actions per rule;
1,000 matched Work Items per scheduled occurrence — an over-limit match set fails preview/run explicitly before applying a partial scheduled set;
100 executions per minute per Organization; excess work is queued fairly.

Templates

Built-in templates instantiate editable, disabled rules: assign on entering In Progress; clear assignment on Done; label stale open work; and transition a parent to Done when all eligible immediate children are Done. A template that needs an assignee or label cannot be enabled until that configuration is complete.

Public API and CLI access

Automation rules are available through Public API v1 with a Personal Access Token granted automation:read or automation:write:

GET/POST /api/v1/organizations/{organizationSlug}/automation-rules;
GET/PATCH/DELETE /api/v1/organizations/{organizationSlug}/automation-rules/{ruleId};
POST /api/v1/organizations/{organizationSlug}/automation-rules/{ruleId}/toggle;
POST /api/v1/organizations/{organizationSlug}/automation-rules/{ruleId}/accept-owner;
POST /api/v1/organizations/{organizationSlug}/automation-rules/{ruleId}/preview;
GET /api/v1/organizations/{organizationSlug}/automation-rules/{ruleId}/runs.

Updates require an If-Match header carrying the rule ETag ("automation-N"), matching the existing optimistic-concurrency convention. Accepting an ownership transfer also requires the current exact ETag. The official Hamstik CLI has no typed automation command yet; use its documented Public API passthrough with the same paths and scopes.