fix(connections): widen CoreCapability with Invoicing, fix capability panel copy

[jakubretajczykBD]

Summary

• Add 'Invoicing' to the frontend's CORE_CAPABILITY_VALUES union, which was missing it even though the backend has accepted this capability since ADR-026 (KSeF, Subiekt, Infakt all declare supportedCapabilities: ['Invoicing']).
• This gap caused ConnectionCapabilitiesPanel to render a false "adapter is not recognized" notice for any Invoicing-only connection (e.g. KSeF) — the panel filters supportedCapabilities through the FE's isCoreCapability guard, so 'Invoicing' was silently dropped and the list looked empty.
• Fix the panel copy itself: replaced the mojibake apostrophe (\u2019 escape leaking into JSX) and the inaccurate "adapter is not recognized" message with an accurate "no capabilities available to toggle here."
• Simplify the PrestaShop/WooCommerce setup schemas to validate enabledCapabilities against the shared CORE_CAPABILITY_VALUES constant instead of hand-duplicated z.enum([...]) literals — this duplication was the root cause of the list drifting out of sync in the first place.
• Update two stale comments in the KSeF setup form/schema that cited the now-fixed CORE_CAPABILITY_VALUES gap as the reason for omitting enabledCapabilities from the create payload.

Related issues

Closes #1287

Test plan

• pnpm --filter @openlinker/web type-check passes
• Updated ConnectionCapabilitiesPanel.test.tsx: renamed the fallback-copy test, added a new case asserting an Invoicing-only connection renders a checked checkbox (not the fallback notice)
• Verified backend consistency independently: CoreCapabilityValues (libs/core), CreateConnectionDto/UpdateConnectionDto (@IsIn whitelist), and the ConnectionService per-adapter supportedCapabilities guard — confirmed PrestaShop/WooCommerce cannot have Invoicing enabled even though the schema's enum is now broader (UI only renders checkboxes for the adapter's actual supportedCapabilities, and the backend independently rejects out-of-scope capabilities)

Quality gate

• pnpm lint passes (zero errors)
• pnpm type-check passes (zero errors)
• pnpm test passes (all unit tests green)
• Optional, Docker required: pnpm test:integration passes — needed
  only if you touched apps/api/test/integration/** or any plugin's
  infrastructure/adapters/.

---

_{By submitting this pull request, I confirm that my contributions
are made under the terms of the Apache License 2.0, and I
certify the Developer Certificate of Origin
by signing off my commits.}

[piotrswierzy]

Review — Approve with changes

Nice, focused fix. I verified the four risk areas and they all hold:

• Backend independently rejects out-of-scope capabilities — ConnectionService.create (L192–198) and update (L366–371) both throw BadRequestException when enabledCapabilities ⊄ metadata.supportedCapabilities. Widening the PS/WC zod schemas to z.enum(CORE_CAPABILITY_VALUES) cannot let PrestaShop/WooCommerce gain Invoicing.
• UI only renders the adapter's own capabilities — the panel filters connection.supportedCapabilities and the create form filters adapterMetadata.supportedCapabilities; neither PS nor WC ships Invoicing, so no Invoicing checkbox is ever offered or submitted.
• Copy fix is real — the old string rendered a literal ’-escape; the replacement is accurate.
• Test — asserts the Invoicing checkbox is checked, 1 of 1 enabled, and the fallback notice is gone. Good coverage, correct accessible-name query, no any.

IMPORTANT — parity is still incomplete

The description says "the FE union now matches the backend CoreCapabilityValues" and frames the shared-constant dedup as fixing "the root cause of the list drifting out of sync." That's only partly true. Backend CoreCapabilityValues has 8 members; this PR brings the FE to 6:

• backend (libs/core/.../adapter.types.ts:22-35): ProductMaster, InventoryMaster, OrderProcessorManager, OrderSource, OfferManager, ProductPublisher, CategoryProvisioner, Invoicing
• FE after this PR (connections.types.ts): ProductMaster, InventoryMaster, OrderProcessorManager, OrderSource, OfferManager, Invoicing

ProductPublisher and CategoryProvisioner are shipped today by both real adapters:

• libs/integrations/prestashop/src/prestashop-plugin.ts:72-73
• libs/integrations/woocommerce/src/woocommerce-plugin.ts:52-53

So on every PrestaShop/WooCommerce connection, isCoreCapability (ConnectionCapabilitiesPanel.tsx:48-49) silently drops those two — the "N of M enabled" counter undercounts and neither is togglable. That's the same bug class #1287 fixes, still open for two capabilities, and the FE constant is still a hand-maintained mirror rather than a genuine single source of truth.

Two ways forward:

1. Add both members here (needs matching CAPABILITY_HELP entries in the two Record<CoreCapability, string> maps, same as the Invoicing entry you already added), or
2. Explicitly scope this PR to Invoicing, file a follow-up for the other two, and soften the "now matches the backend" wording.

SUGGESTION

ConnectionCapabilitiesPanel.tsx:43-47 — the comment justifies the narrow with "the backend's request DTO is still strict on CoreCapabilityValues," but that allow-list is the full 8-member set, so ProductPublisher/CategoryProvisioner are valid to send. The rationale doesn't actually explain excluding them; worth tightening alongside the item above.

The Invoicing fix itself is correct and safe to ship — this is about not overstating the parity claim and closing the same gap for the two capabilities PS/WC already advertise.

[jakubretajczykBD]

SELF TECH-REVIEW

Summary

Small, well-scoped frontend change that widens the FE's CORE_CAPABILITY_VALUES to mirror the backend's full CoreCapabilityValues (adding ProductPublisher/CategoryProvisioner from ADR-024, alongside the already-present Invoicing from ADR-026), and updates the two Record<CoreCapability, string> help-text maps + adds a regression test accordingly. I verified pnpm lint (ESLint), tsc --noEmit, and the affected vitest suite (8/8) all pass, and confirmed the new entries match backend order/naming (ShopProductManagerPort, ADR-024) exactly. No architecture, boundary, or state-ownership issues — this is a pure constant/type/copy fix consistent with the FE-002 "narrow to core caps until the DTO validator lands" pattern already established in this file.

Issues

[SUGGESTION] — apps/web/src/features/connections/components/ConnectionCapabilitiesPanel.tsx, prestashop-setup-form.tsx

▎ npx prettier --check flags both files, but this predates the diff (confirmed via git stash) — the new lines just add two more long single-line object entries in the same already-non-conformant style as their siblings. Not a regression and not gated by pnpm lint (which runs ESLint, not Prettier), so not blocking. Worth a follow-up pnpm format pass sometime, unrelated to this PR's scope.

[SUGGESTION] — apps/web/src/features/connections/components/ConnectionCapabilitiesPanel.test.tsx:120

▎ Test name ('renders togglable checkboxes for ProductPublisher and CategoryProvisioner (shop-listing caps)') doesn't follow the should [behavior] when [condition] convention from docs/testing-guide.md § Best Practices. Every other test in this file has the same drift, though, so this is pre-existing file style, not a new violation worth blocking on.

[SUGGESTION] — apps/web/src/features/connections/api/connections.types.ts

▎ Good catch keeping the two new entries in the exact same order as backend CoreCapabilityValues (libs/core/src/integrations/domain/types/adapter.types.ts) with a comment that correctly names ShopProductManagerPort and ADR-024 — this is the kind of drift-prevention worth calling out as done right, not just an absence of problems.

No BLOCKING or IMPORTANT issues found. I also checked for silent gaps this kind of change typically introduces:

• Other Record<CoreCapability, …> maps that could go stale — grepped the whole FE, only these two exist, both updated.
• Hardcoded capability enums elsewhere (*-setup.schema.ts for PrestaShop/WooCommerce/InPost/DPD) — all derive from CORE_CAPABILITY_VALUES rather than duplicating it, so they inherit the widened set for free; their separate *_FALLBACK_CAPABILITIES allowlists are intentionally explicit and correctly untouched.
• WooCommerce form has no capability-help UI (seeds silently), so no third map was missed.

Verdict

✅ Approve — ready to merge.

[norbert-kulus-blockydevs]

Tech review

Solid, well-scoped FE fix. The capability widening is verified safe end-to-end: backend CoreCapabilityValues already carries all 8 values, ConnectionService.create/update independently reject capabilities outside the adapter manifest (connection.service.ts:194-201, :366-375), both exhaustive Record<CoreCapability, string> maps were updated, the new tests genuinely exercise the regression (an Invoicing-only connection fails the old supported.length === 0 branch), and CI is green (lint / type-check / unit / integration). No architecture, boundary, or security violations.

Findings

[IMPORTANT] Plan + analysis docs contradict the shipped scope
docs/plans/implementation-plan-connection-capabilities-panel-invoicing.md (§2 Out of Scope, §5) and docs/plans/analysis/ANALYSIS-connection-capabilities-panel-invoicing.md - both committed in this PR - explicitly declare widening CORE_CAPABILITY_VALUES with 'ProductPublisher' / 'CategoryProvisioner' out of scope ("defer to a separate follow-up issue"), yet the code in the same diff adds both values, both CAPABILITY_HELP entries, and a dedicated test. The plan's factual premise ("No in-tree adapter currently declares either capability") is also false at head: libs/integrations/prestashop/src/prestashop-plugin.ts:67-74 declares both (ADR-024). The analysis doc additionally claims no Infakt FE setup form exists, while infakt-setup.schema.ts does. The PR description likewise mentions only 'Invoicing'. The code itself is correct - please amend the docs with a short scope-amendment note (ADR-024 caps pulled in because PrestaShop already declares them) and add the addition to the PR summary, so the durable planning record matches what shipped.

[SUGGESTION] Toggle round-trip drops non-core enabled capabilities
ConnectionCapabilitiesPanel.tsx handleToggle (~line 66): enabled is filtered through isCoreCapability, so saving a toggle on e.g. an Allegro connection silently drops ShippingProviderManager from enabledCapabilities, disabling shipping-label generation. Pre-existing and genuinely blocked on the #576 runtime-aware DTO validator, but the rewritten comment frames it only as "not editable from this UI yet" - worth an explicit hazard note or a tracked issue.

[SUGGESTION] Duplicated CAPABILITY_HELP maps
ConnectionCapabilitiesPanel.tsx:22-31 and prestashop-setup-form.tsx:44-54 now each carry three more near-identical entries (and the PS form gains dead Invoicing copy purely to satisfy Record exhaustiveness). This is the same drift shape this PR fixed for the Zod enums. Consider one shared feature-local help map with per-form overrides. Related nit: the panel comment hardcodes "8-member", which will go stale on the next capability addition - phrasing without the count avoids that.

[SUGGESTION] PS vs WC wizard defaults now visibly disagree
With the widen, the PrestaShop wizard's Step 2 renders ProductPublisher / CategoryProvisioner checkboxes but defaults them unchecked (static PRESTASHOP_FALLBACK_CAPABILITIES, prestashop-setup.schema.ts:21-26), while the WooCommerce form reseeds defaults from the adapter manifest (woocommerce-setup-form.tsx:51-59). No regression, but if unchecked-by-default is intentional for the ADR-024 caps, a one-line comment on the fallback list would preempt "why isn't ProductPublisher enabled" reports; otherwise consider adopting the WC reseed pattern.

Verified non-issues: switching PS/WC schemas to z.enum(CORE_CAPABILITY_VALUES) is more permissive than the old 5-member enums, but the loosening is unreachable through the UI (forms seed exclusively from the manifest filtered through CORE_CAPABILITY_VALUES) and the backend manifest guard rejects out-of-manifest values, so behavior is unchanged; trigger-sync-dialog.types.ts uses the type non-exhaustively; the dpd/inpost schema omission comments remain accurate; the KSeF comment updates are accurate; the ’ mojibake is fully removed.

Verdict

Approve with changes - the code is correct and well-tested; fix the IMPORTANT plan/analysis/PR-description scope contradiction before merge.

[piotrswierzy]

PR Review: #1320 — widen FE CoreCapability with Invoicing + panel copy fix

Summary

Correct, well-scoped fix for #1287. Verified the widened FE CORE_CAPABILITY_VALUES now mirrors the backend's CoreCapabilityValues (libs/core/src/integrations/domain/types/adapter.types.ts) exactly — all 8 members including the previously-missing ProductPublisher / CategoryProvisioner (ADR-024) and Invoicing (ADR-026), in the same order and with matching provenance comments. Replacing the hand-duplicated z.enum([...]) literals in the PrestaShop/WooCommerce setup schemas with the shared constant removes the exact duplication that caused this drift, and the two stale KSeF comments citing the old gap are correctly updated.

Positive observations

• The new tests cover both the regression (Invoicing-only connection renders a checked checkbox, not the fallback notice) and the shop-listing capabilities, plus the renamed fallback-copy case — good Arrange-Act-Assert shape and names.
• The mojibake ’ escape leaking into JSX text is gone along with the inaccurate "adapter is not recognized" copy — the new "no capabilities available to toggle here" is honest about what the panel actually knows.
• Widening the PS/Woo zod enums to the full set is safe: the UI only renders checkboxes for the adapter's actual supportedCapabilities, and the backend independently rejects out-of-scope capabilities (verified per the test plan).
• CAPABILITY_HELP: Record<CoreCapability, string> extensions in both consumers — the exhaustive Record type would have failed the build otherwise, nice safety property.

🟢 Optional (non-blocking)

1. FE↔BE mirror drift remains structural. The FE can't import libs/core, so CORE_CAPABILITY_VALUES stays a hand-mirror of CoreCapabilityValues — this PR fixes today's drift but nothing prevents the next one. A tiny check:invariants script comparing the two arrays would close the class of bug permanently. Worth a follow-up issue.
2. CAPABILITY_HELP is duplicated between ConnectionCapabilitiesPanel.tsx and prestashop-setup-form.tsx (pre-existing; this PR extends both copies). Hoisting to a single shared map in the feature would keep the copy from drifting the same way the enums did.

Verdict

✅ Approve — ready to merge as-is; the two suggestions are follow-up material.

[piotrswierzy]

/pr-review — systematic review

Verdict: 🔄 Approve with changes — the code is correct, safe, and well-tested; the required fixes before merge are documentation amendments only (no code changes).

Verified against the live tree

• Backend CoreCapabilityValues (libs/core/src/integrations/domain/types/adapter.types.ts) carries all 8 values incl. 'Invoicing' — the FE 5-member drift and the resulting false "adapter is not recognized" fallback are real; the mojibake ’ escape is real on main.
• The safety chain for the widened zod enums holds end-to-end: setup-form checkboxes/seeds gate on adapterMetadata?.supportedCapabilities ∩ CORE_CAPABILITY_VALUES, and the backend independently rejects out-of-manifest values (@IsIn(CoreCapabilityValues) + the ConnectionService manifest guard). A PS connection cannot end up with Invoicing enabled.
• Only two exhaustive Record<CoreCapability, string> consumers exist in apps/web — both updated here; nothing else consumed the old narrow enums. CI green at head.

🟡 IMPORTANT — amend the record before merge (no code change)

The shipped code contradicts the planning docs it ships alongside, and the deviation is behavior-visible. Both committed docs (docs/plans/implementation-plan-connection-capabilities-panel-invoicing.md §2/§5 and the analysis doc) explicitly defer 'ProductPublisher'/'CategoryProvisioner' to a follow-up, resting on the premise that no in-tree adapter declares them — false at head: both the PrestaShop (prestashop-plugin.ts:67-74) and WooCommerce manifests declare both. The diff widens with all three values anyway, and the PR body mentions only 'Invoicing'. Concretely: (a) the PS wizard now renders two new unchecked checkboxes; (b) every new WooCommerce connection created via the FE now silently seeds ProductPublisher + CategoryProvisioner as enabled (the manifest reseed passes through the now-wider filter — pre-PR it stripped them). I verified this is low-risk (all ProductPublisher consumers are user-initiated publish flows; no scheduler enumerates by it, and it aligns FE-created connections with backend defaulting) — but it's an unannounced behavior change. The analysis doc also has two factual errors ("No Infakt FE setup form exists" — apps/web/src/plugins/infakt/ ships one; ksef-setup-form.tsx cited at features/connections/components/ — actual: plugins/ksef/components/).

Please: amend the PR body + add a short scope-amendment note to both docs (why the ADR-024 caps came along; the WC seed-enable effect) and fix the two factual errors.

🟢 SUGGESTIONS (optional fast-follows)

• ConnectionCapabilitiesPanel.tsx:48-49 — pre-existing lossy-save hazard the rewritten comment glosses over: enabled is filtered through isCoreCapability and the mutation sends a full replacement set, so toggling any core capability on an Allegro connection silently drops its non-core 'ShippingProviderManager'. Blocked on the #576 DTO follow-up, but add one sentence naming the drop hazard (or file a tracking issue).
• ConnectionCapabilitiesPanel.tsx:47 — the comment hardcodes "the full 8-member set"; the count will go stale on the next capability addition (the exact drift shape this PR fixes). Drop the number.
• Two hand-duplicated CAPABILITY_HELP maps now each carry three more near-identical entries (and PS gains dead Invoicing copy for Record exhaustiveness) — consider one shared help map.
• PS vs WC now visibly disagree on ADR-024 defaults (PS unchecked, WC silently enabled) — a one-line comment on PRESTASHOP_FALLBACK_CAPABILITIES would preempt "why isn't ProductPublisher enabled" reports.

✅ Positive observations

• Root-cause fix is right-sized: z.enum(CORE_CAPABILITY_VALUES) eliminates the exact drift mechanism that caused the bug.
• Tests assert behavior, not implementation — the new Invoicing case genuinely fails on pre-fix code.
• No literal platformType dispatch introduced; capability gating stays manifest-driven; mojibake fully removed with a rephrase that avoids the possessive.

(This independently re-verified the earlier review's claims — PS manifest lines, Infakt FE existence, ShippingProviderManager drop hazard — and they all hold.)

[piotrswierzy]

Verified 1696b70e against the review: the scope-amendment note (including the WooCommerce silent-seed behavior change and the PS/WC default disagreement) landed in the plan, both analysis-doc factual errors are corrected, the "8-member" comment is de-numbered, the lossy-save hazard is now documented at the exact filter site, and the PRESTASHOP_FALLBACK_CAPABILITIES comment preempts the "why unchecked" question. All review items addressed — approval stands. ✅

[piotrswierzy]

Re-reviewed at 1696b70e — approval stands. ✅

Verified the merge of main was clean (no main-side deletions; #1297 migration, issuedLineSnapshot, and the #1330 schema seam all intact on the branch — checked explicitly given an unrelated PR tripped on exactly that today), and all 7 CI checks are green at the new head.

Two cosmetic items left for merge time:

1. PR body — it still describes only the Invoicing widen. Since squash-merge derives the main commit message from the title/body, please add one paragraph covering the ProductPublisher/CategoryProvisioner widening + the WooCommerce seed-enable behavior change (the committed plan's scope-amendment note has the exact wording to borrow).
2. Branch is behind main again (fix(shared): export ./worker subpath so worker + api health boot #1331 landed since your merge) — conflict-free update, fix(shared): export ./worker subpath so worker + api health boot #1331 touches nothing this PR touches.