[EPIC] Erli: category/parameter browsing from Allegro's catalog without a required Allegro connection

[norbert-kulus-blockydevs]

Problem / Context

Erli "borrows" Allegro's category/attribute taxonomy by design (ADR-023 §40/§83, ADR-025, #1045) — ErliOfferManagerAdapter declares TaxonomyBorrower.getBorrowedTaxonomy() → 'allegro' but implements neither CategoryBrowser nor CategoryParametersReader. Today the Erli single-offer wizard (apps/web/src/features/listings/components/erli/erli-create-offer-wizard.tsx) only has a plain-text "Category ID" field and no parameters step — unlike AllegroCreateOfferWizard.tsx, which lets the operator browse a category tree and fill required parameters (e.g. "Stan"/condition).

Diagnosis confirmed Allegro's /sale/categories and /sale/categories/{id}/parameters are public catalog endpoints reachable via grant_type=client_credentials (app-level auth, no seller/user OAuth context) — so this can be solved without requiring every Erli operator to own and connect a real Allegro seller account.

Proposed Solution

See the full implementation plan and architecture decision:

• Plan: docs/plans/implementation-plan-erli-allegro-category-catalog.md (merged via docs(plan): Erli category/parameter browsing via Erli-owned Allegro client-credentials token #1380)
• ADR-031: docs/architecture/adrs/031-erli-allegro-category-catalog-via-client-credentials.md — decision: an Erli-owned client_credentials HTTP client, with per-connection-instance dynamic capability wiring (avoiding a regression of the [BUG] Frontend — bulk offer wizard hides category-parameter step for Allegro (required "Stan" unsettable) #1367 bulk-wizard capability gate). Correction found during [TASK] Integration — Erli adapter capability wiring + credentials/config validators for Allegro category access #1383: connection.supportedCapabilities is a static, per-adapterKey manifest value, not per-connection-instance — the actual FE-visible signal is a new non-secret ErliConnectionConfig.allegroCategoryAccessEnabled boolean instead (see ADR-031 "Correction"). Rejected alternatives: requiring a real Allegro connection, a cross-plugin package dependency, and a shared system-wide credential (all documented in the ADR).
• UI mockup (approved): https://claude.ai/code/artifact/5008010f-2c02-4813-8531-30b1e776f26f — checkbox-reveal Allegro credentials in the Erli connection form, plus Category and Category-parameters steps in the Erli offer wizard, built from the live apps/web design tokens.

Three sequential sub-tasks, merged onto one integration branch, with a single final PR (full functionality) opened to main for review:

• [TASK] Integration — Erli-owned Allegro client_credentials catalog client #1382 — Backend: Erli-owned Allegro client_credentials category-catalog client (Plan § Sub-task 1 / Phase 1)
• [TASK] Integration — Erli adapter capability wiring + credentials/config validators for Allegro category access #1383 — Backend: Erli adapter capability wiring + credentials/config validators (Plan § Sub-task 2 / Phase 2)
• [TASK] Frontend — Erli connection credentials checkbox + offer wizard category/parameters steps #1384 — Frontend: connection wizard checkbox + offer wizard category/parameters steps (Plan § Sub-task 3 / Phase 3)
• [TASK] Integration+Frontend — Erli: reuse an existing Allegro connection's credentials for category access #1387 — Integration+Frontend: reuse an existing Allegro connection's credentials instead of a new Allegro app (amendment, mockup: https://claude.ai/code/artifact/84608331-8e91-4960-8544-57d70e2d00fc)

Classification

Type: Integration (Erli) + Interface (FE wizard)
Layer: Application / Infrastructure (backend), Interface (frontend)
File(s): libs/integrations/erli/**, apps/web/src/features/listings/components/erli/**, apps/web/src/plugins/erli/**

Dependencies

• None — this is the tracking epic. Child issues depend on each other sequentially (1 → 2 → 3).

Assumptions

• No cross-plugin dependency between @openlinker/integrations-erli and @openlinker/integrations-allegro (ADR-030).
• No database migration — new fields live in the existing encrypted credentialsRef JSON blob and the existing config JSON column.
• v1 scope: per-connection Allegro app credentials (not a shared, system-wide credential) — see ADR-030 for the deferred alternative.

Acceptance Criteria

• All four child issues ([TASK] Integration — Erli-owned Allegro client_credentials catalog client #1382, [TASK] Integration — Erli adapter capability wiring + credentials/config validators for Allegro category access #1383, [TASK] Frontend — Erli connection credentials checkbox + offer wizard category/parameters steps #1384, [TASK] Integration+Frontend — Erli: reuse an existing Allegro connection's credentials for category access #1387) completed and merged onto one integration branch
• Final PR with full functionality opened to main, referencing Closes #1381
• An Erli connection with valid Allegro app credentials has config.allegroCategoryAccessEnabled: true and its resolved adapter instance passes isCategoryBrowser/isCategoryParametersReader; one without has neither (note: connection.supportedCapabilities itself is unaffected — it's static per-adapterKey, not a per-connection signal)
• The Erli offer wizard renders the Allegro-style category tree + parameters steps when configured, and today's plain-text fallback when not
• The existing [BUG] Frontend — bulk offer wizard hides category-parameter step for Allegro (required "Stan" unsettable) #1367 bulk-wizard capability-gate test suite passes unmodified (no regression)
• No architecture boundary violations (CORE ↔ Integration, no cross-plugin package dependency)