Finish sync mapping persistence + bulk force-sync, fix dead Linear adapter registration

[NathanTarbert]

What this does

Two things on the /sync dashboard used to just return 501 ("not implemented"). Now they actually work:

• Editing status/priority mappings and saving — this used to accept your edits and throw them away. Now it actually persists to the database and the worker picks it up.
• "Force sync" button — used to always fail. Now it actually queues sync jobs for every ticket linked to a plugin.

While digging into why the mapping edits weren't taking effect, found a bigger issue: the worker process never registered a Linear adapter at all. All the code for pushing changes to Linear was there — the adapter, the webhook receiver, the dashboard — but the piece that wires the adapter into the running worker was missing. So outbound sync to Linear has been silently broken this whole time, regardless of any dashboard settings. That's fixed here too.

Also fixed along the way

Ran this through a full review pass (three rounds) before opening the PR, which caught a handful of real bugs:

• Database errors were showing up to users as "invalid request" (400) instead of an actual server error — now they surface correctly
• Couldn't force-sync a plugin the very first time (before it had any sync history) — now you can
• The mapping form would silently accept garbage values and corrupt the config — now it validates properly
• Saving an empty config could silently wipe out real settings — now it's rejected
• A handful of missing test cases around the above

Also added a rule to CLAUDE.md: run the internal CR review before pushing, going forward — this PR is the reason why (it caught real bugs that would've shipped otherwise).

What's intentionally NOT done here

• Priority/label mapping settings save correctly but the worker doesn't act on them yet — only status mapping is wired up (#96)
• The worker doesn't hot-reload config — a settings change needs a worker restart to take effect (#97)
• GitHub isn't touched — this is Linear-only for now (#98)

Testing

515 + 748 + 1 = 1264 tests passing across the three packages touched, full build green, CI green. Also caught and fixed one thing during the pre-push check: a Next.js 15 quirk where route files can't export anything besides the HTTP handlers.

[jerelvelarde]

Code review

Reviewed the diff (endpoints + worker adapter wiring + shared loadStatusMap).

Overview

Three related fixes to the /sync dashboard backend:

1. Mapping persistence — PUT /api/sync/mappings goes from 501 stub to real persistence via the existing SystemConfig key/value table (sync.mappingConfig), with shape + enum validation. GET reads persisted config, falling back to code defaults.
2. Bulk force-sync — POST /api/sync/force goes from 501 to enqueuing TRACKER_SYNC jobs (status + priority) for every TicketExternalLink on a plugin, or a single ticket via ticketId.
3. Dead adapter registration — the worker built a bare new SyncEngine(...) with zero adapters, so outbound Linear sync was silently broken. New buildSyncEngine() calls initializeSyncEngine() and wires in a persisted-config-aware loadStatusMap('linear').

Scope is well-drawn: priority/label acting-on, hot-reload, and GitHub are explicitly deferred to #96/#97/#98 and documented in code.

What's strong

• Test coverage is excellent — each behavioral change has targeted tests: persistence round-trip, malformed-JSON fallback, enum rejection, admin-role gating, empty-config rejection, the 400-vs-500 mislabeling cases, and first-time force-sync with no prior SyncEvent.
• Error-handling fix is correct and deliberate — narrowing the try/catch to wrap only request.json() means a DB/queue failure now propagates as a 500 instead of being disguised as a 400. Locked in by tests (rejects.toThrow('db down')).
• Defense in depth — both the write path (isValidMappingShape) and read path (loadStatusMap) independently validate outpostStatus against the TicketStatus enum, so a hand-edited/legacy DB row can't inject garbage into the running engine.
• First-run force-sync fix (ticketExternalLink.findFirst alongside syncEvent.findFirst) is a genuine bug catch.

Issues & suggestions

1. Dashboard/worker divergence on empty arrays (minor correctness). isValidMappingShape accepts { linear: [] } (non-empty object, vacuously-valid empty array). After save, GET returns statusMappings: { linear: [] } so the dashboard shows no mappings — but loadStatusMap treats entries.length === 0 as "fall back to hardcoded defaults." So the admin sees an empty list while the worker silently keeps using Linear defaults. Consider rejecting empty per-plugin arrays, or having the dashboard reflect the same fallback.
2. Sequential await createJob in a loop (performance). force/route.ts issues 2 × N sequential inserts. For a plugin with many linked tickets this is a long round-trip chain that could brush a route timeout on large workspaces. Promise.all over the links (or a batched insert) would parallelize it.
3. Force-sync isn't atomic (minor). If createJob throws mid-loop, already-enqueued jobs stay and the request 500s with no reported partial count; a retry re-enqueues from scratch (duplicates). Tolerable for a manual admin resync — flagging so it's a conscious choice.
4. prisma as never casts in build-sync-engine.ts are more aggressive than the old as any at suppressing type checks. If StatusMapDb was added to narrow this, consider typing buildSyncEngine against it rather than casting to never.
5. Top-level await buildSyncEngine() makes the worker entry async at module load (behavior change from the synchronous new SyncEngine(...)). Fine under ESM and build is green — just noting.

Security

• Both mutating routes are correctly admin-gated (requireAdmin), GET requires a session, all with tests. ✅
• Config stored as a JSON string and re-validated on read — no injection path into the engine. ✅

Verdict

Approve with minor comments. No blocking correctness or security issues. The dead-adapter fix is a real latent bug worth catching, and test coverage is genuinely thorough. Items #1 (empty-array divergence) and #2 (sequential enqueue) are the two worth a follow-up.

_{🤖 Generated with Claude Code}

[jerelvelarde]

The substance here is good, and the Linear-adapter finding is the valuable part of the PR — outbound sync being silently dead because nothing registered the adapter is exactly the kind of bug that survives indefinitely, since every visible layer (adapter, webhook, dashboard) looked present. Extracting buildSyncEngine() into its own module with its own test is the right shape, and the doc comment explaining that a missing LINEAR_API_KEY yields zero adapters and retried failures rather than silent drops is the sort of thing that saves the next person an afternoon.

The mappings route work holds up: persisting to SystemConfig with the code defaults as fallback, validating outpostStatus / outpostPriority against the real TicketStatus / TicketPriority enums instead of accepting free strings, and rejecting an empty object so a save can't blank out a live config.

Requesting changes mainly because this can't merge in its current state, plus two things I'd like addressed while it's being rebased.

It conflicts with main, and the conflict is a trap

apps/worker/src/index.ts conflicts. The reason is that main has moved since this branched — GITHUB_REACTION_POLL landed (commit e6c871b) and touches the same import block you rewrote.

Concretely, main's index.ts has four references this branch has none of:

17: *   - GITHUB_REACTION_POLL: Poll GitHub reactions on AI comments (no webhook exists)
34:    handleGithubReactionPoll,
59:        [JobType.GITHUB_REACTION_POLL]: 1,
78: worker.on(JobType.GITHUB_REACTION_POLL, handleGithubReactionPoll);

Resolving this by taking your side of the file wholesale — which is the tempting resolution, since your side is the one with the real change — silently unregisters the reaction poll. No test would catch it and no type error would fire; the job type would just stop having a handler. Worth resolving by hand rather than with --theirs.

Dropping createJob from the worker's imports is correct, though — I checked, and its only use on main is the SyncEngine construction your change replaces.

No CI has ever run on this branch

gh pr checks 95 reports "no checks reported on the branch." So the 1264-passing figure is a local result against a six-day-old main that has since taken the reaction poll, the job-table cleanup, and a format/lint pass. Worth re-running after the rebase before this goes in.

as never is doing the job as any was criticised for

build-sync-engine.ts has five of these:

loadStatusMap('linear', prisma as never)
loadPriorityMap('linear', prisma as never)
loadLabelMapper('linear', prisma as never)
deps: { prisma: prisma as never, createJob: createJob as never }
identityDeps: prisma as never

as never is strictly worse than as any here — never is assignable to every type, so it silences the check completely and leaves no marker of what the intended contract was. If SyncEngineDeps gains a required field, none of these break.

The frustrating part is that this PR already defines the right types and then doesn't use them. Your own sync/index.ts change newly exports StatusMapDb, PriorityMapDb, and LabelMapperDb — which are precisely what those first three casts should target — and SyncEngineDeps is exported for the fourth. So:

loadStatusMap('linear', prisma as unknown as StatusMapDb)
deps: {
    prisma: prisma as unknown as SyncEngineDeps['prisma'],
    createJob: createJob as SyncEngineDeps['createJob'],
}

Same deliberate coercion, but it breaks loudly if the contract changes.

Worth knowing that #135 changes these exact lines in the opposite direction — it replaces prisma as any / createJob as any in index.ts with as unknown as SyncEngineDeps['prisma'], for this reason. Two of your own PRs are currently pulling the same wiring apart. See the ordering note at the bottom.

A corrupt config row is indistinguishable from no config

async function readPersistedConfig(): Promise<PersistedMappingConfig | null> {
    const row = await prisma.systemConfig.findUnique({ where: { key: MAPPING_CONFIG_KEY } });
    if (!row) return null;
    try {
        return JSON.parse(row.value) as PersistedMappingConfig;
    } catch {
        return null;
    }
}

A row that exists but won't parse returns null, identically to "never configured" — so GET serves the code defaults, the dashboard renders them as if they were the saved settings, and an admin who deliberately configured a mapping sees it silently reverted with nothing in the logs. Given this PR exists partly because the old endpoint accepted edits and threw them away, that's the same failure shape in a new place. A console.error in the catch (and ideally distinguishing "corrupt" from "absent" to the caller) would make it diagnosable.

Also note the as PersistedMappingConfig on the parse result is unchecked — you wrote isValidMappingShape for the PUT path, but the read path trusts whatever is in the row. A config written by an older version of the code, or hand-edited in the DB, reaches the worker unvalidated.

One question

const syncEngine = await buildSyncEngine(); is a top-level await in the worker's entry module, and it now performs three database queries before the module finishes evaluating. If the database isn't reachable at boot, that throws during import — before the health server starts — so the container crash-loops with no /health at all rather than coming up degraded. Fail-fast may well be what you want here, but it's a change in boot semantics that isn't mentioned, and it interacts with the worker-lifecycle follow-up you flagged on #135 (/health returning 200 on a wedged worker). Worth a sentence either way.

Suggested ordering

Since these overlap: #135 first (it's small, approved, and its SyncEngineDeps casts are in the file you're rewriting), then rebase this one on top. At that point #135's cast lines disappear into your buildSyncEngine() — carry the typed-deps approach into the new module and the as never item above resolves itself in the same pass. Doing it the other way round means #135's typing work lands and is immediately deleted.

The three descoped items (#96 priority/label not acted on, #97 no hot reload, #98 GitHub untouched) are well-drawn boundaries — no objection to any of them being out of scope.

[NathanTarbert]

Rebased onto main and addressed all three change requests. #135 merged on 2026-07-28, so the suggested ordering held — its typed-deps approach is carried into buildSyncEngine() rather than deleted.

The conflict, resolved by hand. You were right that this was a trap: taking this branch's index.ts wholesale would have silently unregistered GITHUB_REACTION_POLL. All four of main's references survive — the header docstring, the import, the concurrencyByType entry, and the worker.on registration. createJob is dropped from the worker's imports as you confirmed; prisma stays, still used by the shutdown path's $disconnect().

as never → named contracts. All five sites now assert to the types this PR already exports: StatusMapDb, PriorityMapDb, LabelMapperDb, SyncEngineDeps['prisma'], SyncEngineDeps['createJob'], and IdentityMapperDeps. Same coercion, but it breaks loudly on drift instead of silently absorbing it.

Corrupt config is no longer indistinguishable from absent. readPersistedConfig returns a discriminated result (absent | corrupt | ok) and logs the reason with the config key. GET now reports configSource ('persisted' / 'defaults') and configError, so the dashboard can say these are defaults instead of presenting them as saved settings.

You also flagged that the read path only cast — fixed. It runs isValidMappingShape against the same TicketStatus / TicketPriority enum sources PUT uses, so a row written by older code or hand-edited in the DB no longer reaches the worker unvalidated. Four new tests cover absent / valid / unparseable / parses-but-wrong-shape, red-green verified (reverting the distinction fails the unparseable case).

On the top-level await. Fail-fast is the intent and the comment now says so: a worker running on silently-defaulted mappings would write wrong statuses to Linear, which is worse than being visibly down, and Railway's restart policy is the retry. The comment also notes the interaction you spotted — once #138's /health work lands, degraded-but-listening becomes a real option and this is worth revisiting.

CI. It had never run on this branch; it has now — green on the merge commit b1bd3a2 (Lint, Typecheck & Test 4m52s, zizmor 13s). Locally on 1a23322: build 10/10, typecheck 10/10, 1,750 tests pass.

Re-review when you have a moment — the PR is mergeable but blocked on this review.

[jerelvelarde]

Reviewed at d57aac8. Both checks green, MERGEABLE.

The dead-adapter catch is the valuable part of this PR — I confirmed against main that the worker was constructing a bare SyncEngine with zero registered adapters, so outbound Linear sync really was dead. And d57aac8 is good work: per-section fallback (one unusable section no longer discards a good one) is better than collapsing the whole row, and rejecting {linear: []} closes a real UI-vs-engine divergence.

That said, d57aac8 closes the items from the 2026-07-18 review, and there's a separate set still open. One of them I'd treat as a blocker.

Blocker — saving the dashboard defaults silently breaks all inbound Linear priority mapping

apps/web/src/app/api/sync/mappings/route.ts:33-39 serves these as the persisted keys:

{ externalPriority: '0 (None)',   outpostPriority: 'MEDIUM' }
{ externalPriority: '1 (Urgent)', outpostPriority: 'CRITICAL' }

But packages/outpost/shared/src/sync/adapters/linear.ts:138 maps with the raw Linear value:

priority: this.mapPriorityToOutpost(String(data.priority ?? '0')),

— i.e. "0"…"4". And apps/web/src/app/sync/mappings/page.tsx:34 PUTs back whatever GET served.

So an admin who edits one status row and hits Save persists a PriorityMap keyed "0 (none)"…"4 (low)", which can never match a real Linear priority. Every inbound priority falls through to TicketPriority.MEDIUM from then on, permanently, with nothing logged.

Worth noting DEFAULT_STATUS_MAPPINGS does match createLinearStatusMap() exactly — priority is the odd one out, which is why it isn't obvious on a read-through.

Fix: persist '0'…'4' and carry "None" / "Urgent" as a separate display-only label field the editor renders.

Also still open

loadLabelMapper drops exclude on any persisted config — label-map.ts:196 returns new LabelMapper({ rules }) with no exclude, and DEFAULT_LABEL_RULES doesn't carry one, so the first save silently disables the wontfix/duplicate/invalid exclusions for GitHub. The doc comment acknowledges it, but it's still silent to the operator. Persist exclude, or merge the factory's list into the persisted mapper.

Writer and readers validate differently. isValidMappingShape picks its key pair via 'externalStatus' in record, so {externalPriority, outpostPriority: 'OPEN'} sitting inside statusMappings passes PUT — then loadStatusMap drops it for having no externalStatus. Same for externalStatus: '': passes PUT (typeof === 'string'), discarded by the loader's truthiness check. That's the accept-then-discard shape this PR exists to eliminate, moved one layer down.

configSource / configError / invalidSections are computed but never read. page.tsx consumes none of the three. The comment on configSource says it exists so the dashboard "can say so instead of presenting them as the saved configuration" — today it still presents them as saved. Wire the banner or drop the fields.

MAPPING_CONFIG_KEY is declared in four files, each with a "must match the key used by…" comment, and the persisted shape is re-declared independently in each. Exporting the key plus one parseMappingConfig() from packages/outpost/shared/src/sync/ and importing it in the route would also collapse the validation-divergence item above.

buildSyncEngine fires three systemConfig.findUnique calls for the same row (build-sync-engine.ts:37-41). Read once, hand the parsed object to three pure builders.

Two new wrinkles introduced by d57aac8

configSource now lies when the whole row is unusable. readPersistedConfig returns status: 'ok' whenever the JSON parses, so a row where both sections fail validation reports configSource: 'persisted' with no configError — where before it correctly reported 'defaults'. corrupt is now reachable only via a JSON parse failure, so the PersistedConfigRead doc comment ("a row that exists but cannot be used indistinguishable from never configured") no longer describes the code. Deriving configSource from invalidSections.length === 0 fixes it.

Related: {...candidate, statusMappings: undefined} as PersistedMappingConfig type-asserts over a non-optional field. It works (?? DEFAULT catches it), but the type is now false — make those fields optional on the interface.

Unbounded Promise.all trades a timeout risk for a pool-exhaustion risk. On a plugin with N links this fires 2N concurrent createJob inserts at once. Prisma queues past the connection-pool limit and rejects on pool-acquisition timeout, so a large workspace still fails — just with a different error. The non-atomicity reasoning in the comment is sound; it's the concurrency that wants bounding (chunks of ~50, or a createMany). Minor: jobs is now (await Promise.all(...)).length, which can only ever be links.length * 2 since Promise.all rejects on any failure.

Tests

Coverage is genuinely strong — ~20 new cases including negative paths, the 400-vs-500 mislabel, first-force-sync-with-no-history, and the empty-config rejection.

The one gap is a round-trip test: GET defaults → PUT them back → assert loadStatusMap / loadPriorityMap produce maps equivalent to the factory defaults. That single test catches the priority blocker and the exclude drop outright, and it's the structural fix that keeps this whole class of bug from recurring.

Smaller notes

• initializeSyncEngine still skips Linear registration silently when identityDeps is absent even with both env vars set (init.ts:55-69). Pre-existing, but this PR is the first thing to call it in production — so it's now exactly the invisible non-registration failure this PR set out to fix. Make identityDeps required, or log.
• InitOptions.deps is required but doc-commented "Override for dependency injection (testing)".
• apps/worker/src/index.ts — the block explaining "this PR moves the engine's construction… main's inline version is therefore dropped rather than merged" is review narration in permanent source. Keep the boot-semantics paragraph (that reasoning is worth keeping), drop the merge archaeology.
• Force route runs two findFirst existence probes and then a findMany that already subsumes the link probe.
• include: { ticket: true } pulls full rows where select: { id, status, priority } would do.
• The new CLAUDE.md rule hard-codes a dependency on copilotkit-internal:cr-loop + the pr-review-toolkit plugin into repo-canonical instructions — an external contributor without those hits an instruction they can't follow. Maybe soften to "run the repo's review loop where available".

Security

No concerns. requireAdmin on PUT/POST and requireSession on GET, plugin validated against existing rows rather than interpolated, both JSON.parse sites guarded, configError returns a fixed reason string rather than echoing row contents.

Verdict

Architecture is right and the direction is good. I'd block on the priority-key mismatch (silent data-correctness bug on the ordinary "open the page, save" path) plus the round-trip test that pins it, and ideally the exclude drop and the configSource regression. Everything else is fine as follow-up.

[NathanTarbert]

Addressed at ad4658e. The priority-key blocker was real and reproduced end-to-end.

The blocker. Confirmed the chain: DEFAULT_PRIORITY_MAPPINGS served '0 (None)'–'4 (Low)' as the persisted keys, LinearAdapter maps with String(data.priority ?? '0') → '0'–'4', and page.tsx PUTs back whatever GET served. One save from the page persisted a PriorityMap nothing inbound could match, and every Linear priority fell to MEDIUM silently from then on. Keys are now the raw adapter values, with the human text in a display-only label the loaders ignore. Your observation that DEFAULT_STATUS_MAPPINGS matched its factory exactly is why priority was the odd one out — nothing on a read-through pointed at it.

The round-trip test. Added and it is the useful one, exactly as you predicted: GET defaults → PUT them back → load through loadStatusMap/loadPriorityMap/loadLabelMapper and assert equivalence with the factories. Red-green verified against both bugs independently — restoring '1 (Urgent)' fails it, and dropping the exclude carry-over fails it. Neither needed a bespoke test.

exclude drop. Fixed via a new LabelMapper.getExcludeList(), so a mapper rebuilt from persisted rules inherits the factory's exclusions instead of quietly losing wontfix/duplicate/invalid.

Validation divergence. isValidMappingShape now takes the expected key pair explicitly rather than inferring it from 'externalStatus' in record, and rejects blank keys the loaders' truthiness checks would discard. Your framing was right — it was the same accept-then-discard shape one layer down.

Both regressions you caught in d57aac8 were mine, and both are fixed. configSource now derives from whether any section survived, so an all-sections-invalid row reports 'defaults' again, and the doc comment describes the code once more. The stripped fields are optional on the interface now, so the delete isn't a type assertion over a field the type claims is always present.

Unbounded Promise.all. Fair — I traded one failure mode for another. Chunks of 50 now, still Promise.all within a chunk so a failure propagates as a 500 (your earlier test pins that), still documented as non-atomic by choice. And you're right that jobs could only ever be links.length * 2; it's computed once rather than accumulated.

The three unread fields. Wired rather than dropped: the mappings page shows a "showing built-in defaults" notice and a per-section "using defaults for X" notice.

Also done: one systemConfig.findUnique per boot instead of three, via a request-scoped read-once facade (pinned by a test); initializeSyncEngine logs loudly when it skips Linear registration for a missing identityDeps — you were right that this PR made it the live version of the bug it set out to fix; InitOptions.deps doc corrected; merge archaeology removed from index.ts with the boot-semantics paragraph kept; force route selects only id/status/priority.

One deliberate deferral. Exporting MAPPING_CONFIG_KEY plus a shared parseMappingConfig() from packages/outpost/shared/src/sync/ — I agree it is the right consolidation and that it would subsume the validation divergence structurally, but it touches all four declaration sites and their tests. That is its own PR rather than something bolted onto this one; the validation fix above closes the correctness half in the meantime.

Also taking the CLAUDE.md note — the review-loop rule shouldn't hard-code a dependency an external contributor can't satisfy. I'll soften it separately so it doesn't ride on this diff.

ad4658e: build 10/10, typecheck 10/10, 1,756 tests pass.

[NathanTarbert]

@jerelvelarde ready for re-review — all four items from the 2026-07-28 review are addressed. Verified against the branch rather than just pointing at commit messages:

Conflict with main. Resolved; GitHub now reports MERGEABLE. The trap you flagged did not bite: GITHUB_REACTION_POLL survives the merge with all four references intact in apps/worker/src/index.ts (header comment, handleGithubReactionPoll import, concurrencyByType entry, worker.on registration).

Corrupt config was indistinguishable from absent. readPersistedConfig() now returns a discriminated { absent | corrupt | ok } instead of null, and an unparseable row logs the parse error plus what it did about it. Went further than asked on one point: validation is per section, so an unusable priorityMappings no longer discards a perfectly good statusMappings — each bad section falls back to code defaults on its own and names itself in the log.

as PersistedMappingConfig unchecked on the read path. isValidMappingShape now runs on read as well as write, with a comment stating the reason you gave — a row written by an older version, or hand-edited in the DB, reaches the worker unvalidated.

Top-level await boot semantics. Documented at the call site rather than left implicit. It records that this is a deliberate change, that fail-fast is the intent (a worker with silently-defaulted mappings writes wrong statuses to Linear, which is worse than being visibly down), that Railway's restart policy is the retry mechanism, and that the decision is worth revisiting once #138 makes /health reflect worker state and a degraded-but-listening mode becomes real.

On your suggested ordering: #135 landed first as you recommended, so its typed-deps approach carried into buildSyncEngine() rather than being deleted. To be precise about what that means — the casts are not gone, but they now assert to named contracts (SyncEngineDeps, StatusMapDb, PriorityMapDb) rather than as never/as any, so a change to those shapes breaks loudly.

CI is green (Lint, Typecheck & Test and Static analysis (zizmor)). The only thing blocking merge is the standing CHANGES_REQUESTED.

Worth noting for scope: the sync-engine issues in #139 — echo detection querying the reverse plugin pair, and inbound changes being discarded while reporting success — are pre-existing and not addressed here. This PR fixes the dead adapter registration and the mappings persistence; the echo-loop correctness work is separate.

[jerelvelarde]

Re-reviewed at ad4658e. The priority-key fix and the round-trip test are right, and the round-trip test is the structural guard that stops that class recurring — good call taking it.

The mappings-route work holds up. What hadn't had a substantive pass from anyone, across four rounds, is the force-sync path — understandably, since the 501 stub made it unreachable until this PR replaced it. Two problems there, both new data/queue-damaging paths this PR opens. I've fixed them in #160, which targets this branch.

1. Outbound status sync silently writes the wrong Linear state

StatusMap.fromOutpost falls back to the first entry of its config when a value has no reverse mapping (status-map.ts:45-53). TicketStatus has six values; createLinearStatusMap() covers four. So WAITING_ON_CUSTOMER and WAITING_ON_TEAM both resolve to Triage — and it records as a successful sync.

Bulk force-sync is the amplifier: one click pushes every linked ticket's current status, so it moves every waiting ticket's Linear issue to Triage at once. But it isn't only force-sync — triggers.ts onTicketUpdated enqueues a status_change job on ordinary ticket updates, reaching the same pushStatusChange → fromOutpost path one ticket at a time. Since this PR is what registers the Linear adapter in the first place, that path goes live with it.

Worth noting GitHubAdapter.mapStatusFromOutpost already handles all six values with an explicit switch — Linear was the only adapter delegating to the guessing map.

#160 puts the guard in LinearAdapter.pushStatusChange so it covers every producer, not just the route.

2. Force-sync accepts plugins with no registered adapter

github-app writes SyncEvent and TicketExternalLink rows, so github clears the route's known-plugin probes — while buildSyncEngine registers Linear only. sync/page.tsx:105 renders a Force button per plugin in the health list, so "Force Github" is a live button that enqueues 2N jobs which each return Plugin is not registered; worker.ts handleFailure retries those to maxAttempts and dead-letters them.

Merge order matters here

#160 is based on this branch, so please don't merge #95 first — that deletes the base and strands the fix. Suggested sequence:

1. Merge fix(sync): stop bulk force-sync from writing wrong statuses and DLQ-flooding #160 into sync-mapping-persistence-bulk-force-sync
2. That push re-runs this PR's CI on the combined code
3. Green → this is good to merge

Step 2 is load-bearing: ci.yml only triggers on PRs targeting main/staging, so Lint, Typecheck & Test never runs on #160 itself — only zizmor does. The combined result gets validated here, on #95, or nowhere. Locally #160 is typecheck 10/10, build 10/10, 1,765 tests.

Filed rather than blocking

• Worker should publish which sync adapters it actually registered #161 — worker should publish which adapters it actually registered (supportsOutboundSync is static; registration is also env-conditional, so the DLQ flood stays reachable by misconfiguration)
• LinearAdapter.pushNewIssue still guesses an initial state for unmapped statuses #162 — pushNewIssue still guesses an initial state, deliberately left; worth an explicit decision
• A skipped sync push still records a success SyncEvent #163 — a skipped push still records a success SyncEvent
• Decide whether WAITING_ON_CUSTOMER / WAITING_ON_TEAM should map to Linear states #164 — product call: should WAITING_ON_* map to Linear states rather than being skipped?
• Sync mappings route: labelRules gaps and two dashboard nits #165 — the five non-blocking findings from my last review (three are the labelRules half of the consolidation you deferred, and they fit naturally into that same PR)

Two things worth flagging

pnpm lint fails in @copilotkit/outpost on a clean checkout of this branch — the repo ships .eslintrc.cjs while the ^9.16.0 range resolves ESLint 9.39.4, which needs flat config. It reproduces with all changes stashed, so it isn't from this PR, but it means my environment and CI disagree about lint and I can't explain why from here. Might be worth a look independently.

Nothing here has been exercised against a real Linear workspace — the Triage behaviour is traced through the code and pinned with mocked red-green tests, not observed live. Given this PR is what makes outbound Linear sync work at all, a manual smoke test on one ticket before merge would be time well spent.

Happy to re-review once #160 is in and CI is green here.

---

Generated by Claude Code