Motivation
Testing Local Artificer with issue #217 required manually supplying the state path, repository and checkout, ticket scope, recurring authority, credential location, and installed delivery plugin roots before initialization. The setup feels too heavy for the common local case; inferable values should have sensible defaults that remain explicitly overridable.
After a skill-launched tick, there is no ongoing foreground explanation of what the local delivery is doing. Status is visible only through a separate request, which makes the running process hard to understand locally.
The current experience also creates uncertainty about whether GitHub is hardcoded into Artificer. Ticket access should remain replaceable in the same spirit as darrow-tickets-github, so users choosing another ticket system have a supported capability boundary rather than GitHub-specific polling in the automation layer.
Acceptance criteria
- Common local initialization uses sensible defaults for inferable configuration while preserving explicit overrides and required safety confirmations.
- A delivery launched through
manage-artificer provides periodic foreground status that explains what it is doing and what action, if any, is needed.
- Artificer's ticket-provider boundary is explicit and supports ticket polling through a compatible ticket capability rather than requiring GitHub-specific behavior in the automation core.
Open questions
- Which initialization values can safely default, and which must remain explicit confirmations?
- Should skill-launched foreground status poll every 30 seconds, or use another interval or event-driven mechanism?
- What provider-neutral contract should Artificer consume from ticket capabilities?
Motivation
Testing Local Artificer with issue #217 required manually supplying the state path, repository and checkout, ticket scope, recurring authority, credential location, and installed delivery plugin roots before initialization. The setup feels too heavy for the common local case; inferable values should have sensible defaults that remain explicitly overridable.
After a skill-launched tick, there is no ongoing foreground explanation of what the local delivery is doing. Status is visible only through a separate request, which makes the running process hard to understand locally.
The current experience also creates uncertainty about whether GitHub is hardcoded into Artificer. Ticket access should remain replaceable in the same spirit as
darrow-tickets-github, so users choosing another ticket system have a supported capability boundary rather than GitHub-specific polling in the automation layer.Acceptance criteria
manage-artificerprovides periodic foreground status that explains what it is doing and what action, if any, is needed.Open questions