| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
New spec at `docs/saved-query-sync-spec.org` for promoting local `pearl-saved-queries` entries to Linear custom views (`customViewCreate` / `Update` / `Delete`). Written end to end on 2026-05-28 and walked through a six-question sprint review the same day. Status moves Draft to Ready.
The live-API probe drove two substantive simplifications. `CustomViewCreateInput.filterData` is type `IssueFilter`, the exact type pearl's existing `pearl--build-issue-filter` already produces, so the proposed filter-mapping helper collapses to a pass-through and implementation phase 1 becomes a sanity-test commit rather than new code. Linear's API has no `customViewArchive` (only Delete), so the delete-or-unlink prompt on the extended `pearl-delete-saved-query` is the actual choice rather than archive-or-unlink. No sort-order input on the view mutations either, so syncing pearl's `:sort`/`:order` moves to vNext.
The review itself surfaced one further design move beyond resolving questions: collapsing the two prompts the spec originally proposed (team scope plus shared flag) into a single enriched prompt where each candidate is a complete end-state (`[ Team: Engineering, visible to the team ]` etc.). The same enrichment pattern then applies to `pearl-pick-source`'s label for synced entries (`[saved → Engineering] Name`). Two pattern-catalog candidates noted for the running rulesets discussion.
Implementation decomposes into seven independently-shippable phases, enumerated in the spec's `Implementation tasks (drop-in for todo.org)` section per the spec-review workflow update sent to rulesets earlier in the session. Tasks land in `todo.org`'s Pearl Open Work alongside this commit.
|
| |
|
|
|
|
|
|
|
|
| |
Pearl now treats Linear sources (favorites, custom views, ad-hoc filters, saved queries) as one surface. `pearl-pick-source` is the unified picker: it lists every Linear favorite alongside every locally saved query, and dispatches by kind. View / project / cycle / label / user favorites resolve to runnable filter or view sources; issue / document / dashboard favorites open in the browser since they aren't lists.
The filter compiler grows id-based forms (`:label-id` and `:assignee-id`), so favorites that name a Linear entity (a user, a label) compile to rename-proof queries rather than fragile name matching. The ad-hoc builder gets a matching member-assignee option ("me / member / any"), so a one-off "what's a teammate working on?" doesn't require building a saved query first.
Two pre-existing builder bugs surfaced during verify and got fixed in the same pass. The builder previously passed display names straight to the compiler, but `:team` compiles to `team.key.eq` and `:project` to `project.id.eq`, so Linear rejected every builder run that pinned a team or project. Now the builder resolves the picked name to its key / id before assembling. And `pearl-list-issues-by-project` previously injected `:assignee :me` into the filter, hiding every teammate's work in the project. It now returns the whole project.
The save prompt on the builder was rewritten so the local-only nature is unambiguous, and the README grew a Sources section plus a keymap-table entry for `f s`.
|
| |
|
|
| |
I drafted a design for unifying Pearl's fetch surface around sources: read the viewer's Linear favorites and run them by type-dispatch behind one pearl-pick-source picker, with the per-dimension filters as the primitives favorites resolve into and the ad-hoc builder as the exploratory fallback. It fixes the by-project me-lock and resolves label and user favorites by stable id, which needs two small filter-compiler forms (:label-id, :assignee-id). The Linear favorites schema is verified against the live API and Codex's review is incorporated, so the spec is Ready.
|
| |
|
|
| |
The spec predates save-model-v2, which removed the org-sync push path its "sync-back: cycled keyword → Linear state" section relied on. Mark that section obsolete: state now reconciles at save through pearl--save-state-field, and the cycled-keyword → state-id resolution is the c8 task. Record the invariant c8 leans on — every fresh render sets the keyword to slugify(state-name) — and the one stale-render caveat a refresh closes.
|
| |
|
|
|
|
| |
The v2 spec folds the structured fields — priority, state, assignee, labels — onto the save engine and removes immediate push, so the package has one write path instead of two. It extends the shipped v1 save-model spec and supersedes the "field setters stay immediate" half of v1 decision 8. I incorporated two Codex review rounds.
I also added the supersession pointer to the top of the v1 spec so the v1/v2 relationship is legible from either file.
|
| |
|
|
| |
I ran the live check the spec named as its one prerequisite: WorkflowState.position exists and returns a float (Dev Review 947.14, In Progress 2, Planning 0), so the per-team position ordering works as designed and the no-position fallback is unnecessary. Recorded it in the status and prerequisites and folded in the round-5 review (the only finding was that status/rubric hygiene). The spec is now cleanly READY with no open prerequisites.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I folded the Codex reviews into four draft specs and brought each to Ready. The reviews surfaced real failure modes, not nits, so the changes are substantive.
The comment-deletion spec is Ready: I verified Linear's commentDelete contract against the live API. The mutation is commentDelete(id: String!) returning success, and the comment is not found immediately after, so there's no restore path and undo is impossible. The dirty-local-comment policy is allow-with-discard-wording, the prompt names both the remote delete and the local removal, and the d c keymap / K transient slots are settled.
The multi-account spec is Ready. The original "set the globals on switch and let downstream stay oblivious" model leaked across accounts in the async code, so it's redesigned around an account-context layer: dispatch-time context snapshots, #+LINEAR-ACCOUNT file ownership with wrong/unmarked-buffer guards, a runtime (not persisted) active-account, a mode-line indicator, and an exact startup rule. The five safety calls are settled as the safer defaults.
The sort-order spec is Ready. Client-side sort now moves whole issue subtrees by LINEAR-ID byte-for-byte rather than reparsing and rewriting, which would have dropped unsaved edits. Header persistence is atomic with the reorder, and Custom Views refuse server-side sort in v1 since customView.issues has no verified orderBy.
The labels-as-org-tags spec is Ready: collisions render the shared tag once with the drawer authoritative, Pearl owns the whole issue-heading tag set, manual tag edits are overwritten and never pushed, and Unicode alphanumerics are preserved.
|
| | |
|
| |
|
|
| |
Two design specs for upcoming work. ticket-save-model-spec covers the unified "save the ticket" model — diff title/description/comments against their provenance hashes and push only what changed, with a sequential conflict-aware engine and an opt-in keymap — and went through two review rounds (Codex). multi-account-spec covers switching between work and personal Linear workspaces over the existing globals, with auth-source credentials and per-account cache isolation; it's still pre-review draft.
|
|
|
Pearl fetches Linear issues into an org file and syncs edits back. It covers list / custom views / saved queries, per-issue and bulk rendering with comments inline, conflict-aware sync of descriptions, titles, and comments, field commands for priority / state / assignee / labels, and a transient dispatch menu. The render folds to a scannable outline and nests issues under a sortable parent.
Based on and inspired by Gael Blanchemain's linear-emacs.
|
