Struct LinearAdapter 

pub struct LinearAdapter { /* private fields */ }

The linear-cli adapter. Spawns linear-cli issues <list|get|create|update> with the configured team and, when a secret is configured, the LINEAR_API_KEY env pair.

Implementations

impl LinearAdapter

pub fn new( runner: impl CommandRunner + 'static, token: Option<String>, team: String, ) -> Self

Trait Implementations

impl TrackerAdapter for LinearAdapter

fn mark_done(&mut self, _remote_ref: &str) -> Result<()>

Linear conveys done via -s Done; there is no close command.

fn list_open(&mut self) -> Result<Vec<RemoteIssue>>

Enumerate open issues with issues list, then fetch each one’s detail.

The list payload carries only id, identifier, title, priority, state{name}, assignee{name}, project{name} — never a body, labels, or timestamp — so the fields an import needs come from a per-issue issues get. Cost: one list call plus one get per open issue.

fn set_relations( &mut self, remote_ref: &str, relations: &[MappedRelation], ) -> Result<()>

Linear’s relations add, the relation affordance the 0.3.28 CLI exposes.

One call per relation, because relations add is additive and creates a single edge: -r <RELATION> <FROM> <TO> with the relation kind and the two issues’ remote identifiers (ENG-123); the target identifier is what crate::sync::map_relation_to_remote resolved and carried in value. The first failure stops the run: a partially-created relation set is worse than a loud stop, and export is not transactional across issues either, so a diagnostic-free partial state is exactly what a reader cannot detect.

fn set_projects( &mut self, _remote_ref: &str, projects: &[MappedProject], ) -> Result<()>

Linear’s side of the project-association seam — and its answer is “nothing” (WP08 T036).

Linear’s issue carries one project, so a second membership has nowhere to go: there is no list field and therefore no command line that could carry one. Sending the first association and diagnosing the rest would split one membership rule across two places and quietly drop data; C-005’s answer for all of them is the diagnostic, and the local list stays whole.

The debug_assert pins the same invariant as GitLab’s: a value cannot arrive while PROJECT_WIRE_VERIFIED is empty, and a table flipped without an implementation here fails loudly in every test build rather than dropping an association in silence.

fn set_epics(&mut self, _remote_ref: &str, epics: &[MappedEpic]) -> Result<()>

Linear’s side of the epic-reference seam — and its answer is “nothing” (WP08, mission epics-work-items-01M3BYW4).

Linear has no epic level at all: its issues carry one project, and the nearest concept above a project is an initiative. Neither issues list nor issues get returns an epic field, so there is nothing to read and no field to send.

The debug_assert pins the same invariant as GitLab’s: a value cannot arrive while EPIC_WIRE_VERIFIED is empty, and a table flipped without an implementation here fails loudly in every test build rather than dropping a reference in silence.

fn tool(&self) -> Tool

fn create_issue( &mut self, title: &str, body: &str, labels: &[String], _assignee: Option<&str>, priority: Option<&str>, status: &str, ) -> Result<String>

Create a remote issue and return its remote id (GitLab iid, Linear identifier).

fn update_issue( &mut self, remote_ref: &str, title: &str, body: &str, labels: &[String], _assignee: Option<&str>, priority: Option<&str>, status: &str, ) -> Result<()>

Update an existing remote issue in place.

fn done_via_status(&self) -> bool

Linear sets done through the status flag; GitLab needs a separate close call.