Перейти до змісту

План проекту ESWF / DOP

Архітектура, tech stack, структура модулів — у ../CLAUDE.md та dop/spec.md. Цей файл — лише активний backlog. Виконане → done.md. Відкладене з тригерами → BACKLOG.md.

Як читати backlog

Класифікація задач для autonomous mode (деталі — ../CLAUDE.md § Autonomous task execution): - 🤖 auto — Claude виконує самостійно від плану до коміту, дрібні розвилки → ADR. Береться у batch-режимі. - 🧭 review — Claude виконує, але стоп після коміту. Скіпається у batch. - 👤 decision — Claude НЕ пише код, готує ADR-пропозицію з варіантами. Скіпається у batch. - без маркера — лише в інтерактивній сесії, не запускати автономно.

Класифікація задач по треках (memory three-tracks-discipline, three-tracks-definition): - [ESWF] — framework: core/, form-shell, common/fields/list/toolbar, skills, AFP framework - [ESS] — Essentials horizontal ERP: essentials/, accounting/, crm/, hrm/, production/, plugins - [SHC] — ShipCore vertical: fleet/, logistic/, shipcore/, mobile/, compliance - (+TAG) — spillover, додатково зачеплений трек

Пріоритет (memory feedback_priority_criteria — порядок: архітектурна правильність → рівномірний розвиток треків → відповідність західним ERP стандартам): - P0 — блокує architectural completeness або працюючий pattern зламано. Беремо першим. - P1 — завершує нещодавно landed pattern, заповнює відомий gap у коді, тех-борг від MVP. Активна черга. - P2 — completeness/uniformity без архітектурного blocker'а. YAGNI поки не зробимо shape. Беремо коли P0/P1 спорожніли.

НЕ використовуємо як тригер активації (memory feedback_no_client_triggers, feedback_priority_criteria): - ❌ «коли клієнт X підпише», «коли pilot активує», «коли operator-side запит» - ❌ «pilot signal на конкретний document type / dashboard / report» - ❌ «при потребі демо для pilot client»

Валідні тригери реактивації: - ✅ «хочу зараз» / «потім» від користувача - ✅ Architectural prerequisite landed (e.g. «Phase 4 refactor closed → Phase 7 pricing concept unblocked») - ✅ Real external dependency resolved (e.g. Maersk creds in hand, УЗ B2B-договір підписаний) - ✅ Regulatory deadline approaching (eTTN 2027-01-01, eFTI 2027-07-09) - ✅ Data-driven threshold crossed (e.g. «коли unmapped Group MDM entries > 1000»)

При першому «далі»/«продовжимо»/«наступна» у сесії — Claude робить git lookback по треках за 14 днів і пропонує сплячий трек.

🟢 P1 — активна черга

[ESS] OpeningBalance Phase 6b — period mode для Inventory/Party/FixedAsset/Fuel handlers (+ESWF) 🧭

  • Арх.бенефіт: завершує handler-registry symmetry для OpeningBalancePeriod. Phase 6a Account handler shipped 2026-05-22; реєстр має optional period_line_model / post_period / unpost_period, інші 4 handler-и no-op. Без них Phase 6 закриває тільки account-driven звіти (TB/P&L/Cash Flow), але не aging-by-month / inventory backfill / depreciation history / fuel consumption history.
  • Western ERP ref: NetSuite «Historical Transaction Import» / Dynamics 365 «Mid-Year Adoption» / SAP «Mass Period Upload» — всі підтримують ретроспективний import по ВСІХ register types, не тільки GL accounts.
  • Деталі: 4 окремі shape-сесії (одна на handler), кожна потребує власного ADR-рішення:
  • Inventory — per-batch granularity vs ledger-only aggregate. Якщо per-batch — як рахувати FIFO собівартість періоду коли в DOP ще не було даних? Як уживатися з batch'ами з Phase 1-5 state-at-date?
  • Party — per-partner aging-by-month окремо vs derivation з Account handler через 361/631 ledger aggregates. Дублювання чи додаткова цінність?
  • FixedAsset — double-count guard. Phase 1-5 snapshot prior_accumulated_depreciation + переписує accumulated_depreciation. Period mode мав би додавати depreciation expense Дт 92 / Кт 13 щомісяця. Як гарантувати що не задвоюється з snapshot'ом «накопичена на дату»?
  • Fuel — fleet-specific consumption history. Які звіти будуть (cost per km / consumption rate / write-off summary)?
  • Pattern для extension — period_line_model = ... + post_period(doc) + (optional) unpost_period(doc) для non-Posting registers. ADR Phase 6a показує приклад на Account handler. Кожен з 4 — ~1 день shape + ~1 день код.

[ESWF] Dashboard — GatehouseDashboard top-strip integration з WidgetActivity (+ESS) 🧭

  • Арх.бенефіт: первинний real consumer для WidgetActivity + useWebSocketWidget primitives shipped 2026-05-22 (S5-mini). Без одного production-usage validation эти primitives залишаються mertvыми patterns (registry has widget, але жодна сторінка не консьюмить). Архітектурно — pattern verification через single deliberate consumer перед mass-adoption.
  • Western ERP ref: Dynamics 365 Field Service Operator Board / Salesforce Lightning Live Tiles / NetSuite SuiteSuccess real-time dashboards — все мають real-time push-aware operator overview зверху navigation menu.
  • Деталі: доповнити поточний GatehouseDashboard.tsx (зберігаючи TerritoryMap + gate-points grid + tabs) додатковою dashboard-стрічкою зверху: 3 cue widgets (queue today / weighings in progress / today's events) + права панель WidgetActivity з gatehouse.recent-events. Wire через useWebSocketWidget({ url, invalidateOn: ['gate_event_created','weighing_ticket_updated'] }). Не замінює існуючий dashboard, доповнює зверху. ~4-6 годин. Scope-cut: InventoryDashboard НЕ мігрується (це ProcessPage, не dashboard — підтверджено audit 2026-05-22).

[ESS] GateOperator settings drawer 🧭

  • Арх.бенефіт: заповнює відомий TODO у коді (GateOperator.tsx:1049 — кнопка Settings показує Coming soon notification). MVP gatehouse закрито з цим debt пунктом. Доводить gatehouse module до feature-complete.
  • Western ERP ref: Dynamics 365 Field Service per-station settings / NetSuite Manufacturing Cell configuration — універсальний паттерн drawer з 3 категоріями (whitelist / policies / equipment status).
  • Деталі: drawer з 3 секціями: (1) Auto-accept whitelist — vehicle-profiles що пропускаються автоматично; (2) Exit-without-tare policy — toggle для VIP-візитів (представник з документами без вантажу); (3) Equipment binding mapping — live-view gate-equipment з last_seen_at. Backend: GatePointSettings модель або розширення GatePoint. Frontend: Mantine Drawer з Accordion або Tabs. Acceptance: drawer відкривається, 3 секції рендеряться, зміни persistuються, equipment status оновлюється через existing WS hook.

[ESWF] AFP Phase 1 — core/federation MVP framework 🧭

  • Арх.бенефіт: уніфіковане federation foundation для (1) baf_sync (existing production), (2) cross-tenant консолідації, (3) міжнародної UA+MD→DE консолідації, (4) shop-sync, (5) MDM hub. Зараз baf_sync — bespoke transport з власними outbox/log патернами. AFP Phase 1 = single framework що уplifts всі 5 use cases.
  • Western ERP ref: NetSuite OneWorld intercompany + SuiteCloud platform / Dynamics 365 Intercompany Accounting / SAP Group Reporting — все мають abstract federation layer над transport-specific implementations.
  • Деталі: Django app core/federation; моделі FederationPeer, OutboxMessage, InboxMessage, FederationAuditLog; Transport Protocol interface + два concrete (InProcessTransport, HttpsBearerTokenTransport); envelope schema Pydantic (message_id/source/target/payload_type/payload_version/payload/created_at/supersedes); payload type registry pluggable; outbox worker management command; inbox endpoint /api/v1/federation/inbox з bearer auth; idempotency by message_id; тести send/receive round-trip + duplicate + audit. Identity: існуючий TenantAwareModel.uuid. НЕ робимо: JWT ed25519, async ACK, supersedes обробка, FX, conflict resolution — Phase 4-5. ~1 тиждень.

[ESS] AFP Phase 2 — baf_sync uplift на AFP (+ESWF) 🧭

  • Арх.бенефіт: мігрує existing production baf_sync на новий framework через shadow-mode → одна implementation для federation замість двох. Валідація AFP Phase 1 contract'у через real production workload перед Phase 3.
  • Western ERP ref: аналог канонічного «adapter retrofit» (NetSuite SuiteScript → SuiteCloud upgrade, SAP legacy IDoc → SAP PI/PO uplift). Pattern: запустити обидва шляхи паралельно, порівнювати payload, перемкнути per-tenant pilot після паритету на 100+ повідомленнях.
  • Деталі: payload types master_data.sync.v1 (Client, Item) + operational.document.v1 (Invoice); BAFTransport рефакториться як implementation core.federation.Transport; BAFSyncLog → OutboxMessage з peer.transport_type='baf'; BAFEntityMapping лишається як external UUID adapter; payload builders → handlers; shadow-mode rollout per-tenant; existing baf_sync tests pass без змін на surface API. Risk mitigation: per-tenant rollout (один → тиждень → rolling). Залежить від Phase 1. ~2-3 тижні.

[ESS] AFP Phase 3 — Group Master Data Hub MVP (manual reconciliation) (+ESWF) 🧭

  • Арх.бенефіт: symmetry групового обліку — окремі tenants (UA-T1, UA-T4) можуть мати свої локальні Items/Partners/Accounts, але група бачить «один canonical Product». Закриває третій великий use case AFP (consolidator-side MDM hub).
  • Western ERP ref: NetSuite Multi-Subsidiary Items / SAP Material Master Federation / Dynamics 365 Master Data Services / Odoo Multi-Company Catalog — convergent pattern для groups.
  • Деталі: canonical моделі GroupProduct/GroupPartner/GroupAccount (на consolidator-side); mirrored моделі MirroredItem/MirroredPartner/MirroredAccount; локальні FK на subsidiary; hierarchical GroupProduct catalog; generic Reconciliation Workspace Kanban для всіх 3 entity types (filter strip, колонки Unmapped/Suggested/Confirmed, per-card source badge + manual search + approve + defer, bulk approve); "Unclassified" bucket у group reports; dual-axis report (sales summary by source / by group product); optional requires_explicit_mapping flag. Тестується intra-server: UA-T1 mirror → UA-T4 з MDM hub. Залежить від Phase 2. ~2-3 тижні.

[SHC] Concept session — shipcore_pricing Phase 7 (+ESS) 👤

  • Арх.бенефіт: unblocked since Phase 4 refactor closed 2026-05-21. Внутрішні блокери (Cash & Bank S6-S8, Fleet↔ESS bridge, OpeningBalance) — всі closed. Без Phase 7 concept ShipCore залишається без freight pricing — критична gap для logistics product. ESS-side формула CPM (амортизація / fuel / driver payroll) уже доступна.
  • Western ERP ref: Oracle Transportation Management Quote Builder / SAP TM Charge Management / MercuryGate Pricing Workbench / Mercury Bridge LaneIQ — всі мають layered pricing (base + FSC + accessorial + lane history + margin band).
  • Деталі (concept document scope): (1) costing — CPM по TU (фікс/змінні/driver pay); (2) lane history — внутрішній DAT-замінник, tenant-private; (3) quote builder — три цифри (floor / median / margin band); (4) Fuel Surcharge окремим полем; (5) deadhead-фактор для зворотного порожнього пробігу. Output — ADR + entity-spec для backend/shipcore_pricing/ (TariffPlan/FSC/Accessorial + LaneRateHistory). На основі research planning/truck-freight-pricing-western.md. НЕ блокер ShipCore — частина roadmap.

[SHC] Phase 5 Day-9+ — Frontend frontend/dop/sea/ shape session для 8 ocean components 👤

  • Арх.бенефіт: sea/ backend закрите (Phase 5, 7 моделей + 4 services + DCSA codegen). 3 placeholder dashboards у 9180d63. 8 real components залишаються без UX shape — потрібна окрема shape-сесія щоб не писати green-field design в коді.
  • Western ERP ref: Mercury Gate / CargoWise / Descartes — всі мають Gantt-style schedule board + Kanban booking workflow + 3-stage BL editor. DCSA-compatible BL print template — industry-standard від 2023.
  • Деталі (shape session output): ADR з UX decisions для 8 компонентів per sea.md § 3.4: VesselScheduleBoard (Gantt — time-slot resolution? drag-to-reschedule?), OceanBookingForm + OceanBookingDashboard (Kanban — stages Draft/Confirmed/Cut-off/On-board? drag-drop semantics?), VGMEditor (single-page form? per-equipment matrix?), BLEditor (3 stages — Original/Sea waybill/eBL — UX state transitions), BLPrintPreview (DCSA template structure), DemurrageDashboard (WebSocket countdown UX), OceanTrackingMap (Leaflet + AIS layer choice — Vizion vs MarineTraffic?). Без UX shape — спекуляція в коді.

[ESS] Variant reports UI — shape session 👤

  • Арх.бенефіт: backend BI views (vw_sales_fact/vw_purchase_fact з variant_attributes JSONB) готові у V5 закритому 2026-05-21. Frontend reports не зроблено. Asymmetry: дані готові, UI ні. Architectural debt малий, але закриває full variants stack.
  • Western ERP ref: NetSuite Item Matrix Sales Report / SAP Variant Sales by Configuration / Dynamics 365 Product Variant Profitability — convergent pattern «sales by template × attribute».
  • Деталі (shape session output): ADR з вибором: (a) додати report до існуючого @core/components/Reports framework з ReportDefinition — натура DOP'у, але звужує до tabular sortable view; (b) Mantine Charts матрицю «Sales by template × attribute breakdown» — visual, але off-framework; (c) drill-down з template row у Items list — мінімальний код, але не агрегатний звіт; (d) external (PowerBI/Metabase) через існуючі views — нічого не пишемо, документуємо як supported path. Без ADR — кожен вибір == green-field design.

Tech debt — useQuery без enabled: hasPlugin(...) у plugin-gated компонентах 🧭

  • Арх.бенефіт: виправляє baseline issue — компоненти з plugin: 'sales_field' | 'hrm' | 'logistic' ще useQuery-ять навіть коли plugin вимкнений (через bookmark, browser history, Recent у V2 task-nav). Backend 403 spam у логах, особливо через refetchOnWindowFocus + KeepAlive. Зараз useFilteredSections фільтрує тільки навігаційне приховування, не data fetching.
  • Western ERP ref: universal pattern в React-ERP — Salesforce Lightning checks $Permission, Dynamics Power Apps checks IsEntityEnabled, NetSuite SuiteScript checks isFeatureInEffect. Не feature, а correctness fix.
  • Деталі: уніфікований паттерн useQuery({ enabled: hasPlugin('<key>'), ... }) у всіх plugin-gated компонентах. Перший виявлений — SalesFieldManager (~5 useQuery виклики); потенційно є аналогічні у HRM, Logistic, ContainerHub. Додатково: <ModuleUnavailablePage /> коли plugin не активний (як SectionPage comingSoon, але інший шлях). Виявлено під час V2 task-centric-nav тестування.

🟡 P2 — completeness / без архітектурного blocker'а

[ESS] Variants V4b extension — wire VariantPicker у 8 решта line types ⏸️

  • Арх.бенефіт: uniformity completion — V4b 2026-05-21 закрило 4 high-traffic line types (Invoice/PurchaseInvoice/GoodsReceipt/GoodsShipment). 8 решта (WriteOff/Count/Manufacturing×2/POrder/SOrder/Transfer/SalesReturnMobile) залишаються БЕЗ variant column. Pattern уже встановлений у V4b commit, кожен document ~15 хв роботи. Mechanical port.
  • Western ERP ref: NetSuite Item Matrix uniformly applies to all transaction subforms (Sales/Purchase/Inventory/Manufacturing). DOP має 4/12 — 33% covered.
  • Деталі: backend serializer denorm (item_is_template + variant_sku + variant_attribute_signature) + frontend variant column (hasPlugin gate + item_is_template gate + VariantPicker). Можна закрити одним batch session (8 × 15 хв = ~2 години). Залишилось: GoodsWriteoffSubtables, InventoryCountSubtables, ManufacturingInputSubtables + ManufacturingOutputSubtables, PurchaseOrderSubtables, SalesOrderSubtables, StockTransferSubtables, SalesReturnMobile (sales_mobile_api).

[ESS] vw_stock_balance BI view — variant-aware stock snapshot ⏸️

  • Арх.бенефіт: BI view symmetry — vw_sales_fact + vw_purchase_fact готові з variant breakdown (V5). vw_stock_balance був би третій leg «sales / purchases / inventory» star-schema. Зараз inventory snapshot доступний тільки через runtime JOIN Batch ← ItemWarehouseStock ← BatchReservation.
  • Western ERP ref: NetSuite Saved Search Inventory Balance / SAP MM Stock Overview — стандартний third leg після sales/purchase aggregates.
  • Деталі: нова BI view rows per (item, variant, warehouse, batch) per ADR D-3. Аггрегує Batch + BatchReservation + StockTransaction у point-in-time snapshot. Підтримує PowerBI/Metabase live dashboards без runtime JOIN. Existing ItemWarehouseStock denorm (з V3 variant FK) покриває швидку CRUD-перевірку, але не star-schema queries.

[ESWF] Phase B.5 — per-tenant capability toggle (Tenant.enabled_capabilities + Admin Tools UI) ⏸️

  • Арх.бенефіт: infra pre-req для plugin economy. Зараз ESWF_PLUGINS env var — global на весь backend. Архітектурно неправильно для multi-tenant SaaS позиції — два tenants на одному сервері мають identical plugin set. Architecture зафіксована adr-2026-05-18-frontend-core-capabilities, implementation відсутня.
  • Western ERP ref: NetSuite Bundles (per-account bundle activation), SAP Add-Ons (per-client opt-in), Odoo Apps Marketplace (per-database install), Dynamics ISV Solutions (per-environment) — convergent pattern.
  • Деталі: Tenant.enabled_capabilities: JSONField (null=all-enabled / []=none / ['perms','smtp']=explicit) + useCapabilities() hook + Admin Tools → Capabilities UI + PATCH /api/v1/admin/tenant/. Cross-cutting infra для всіх 27+ plugin'ів. Shape питання: per-tenant vs per-role vs per-module-config — потребує ADR перед implementation. До shape-сесії — speculation.

[SHC] Product Variants Phase B — ShipCore грузообработка adapter (+ESS) ⏸️ 👤

  • Арх.бенефіт: generalize-before-specialize (memory feedback_generalize_before_specialize). V1-V5 universal landed без прокат-bias 2026-05-21. Phase B = специфічний adapter поверх universal: прокат-attributes (Метал/Профіль/Діаметр/ГОСТ/Партія), Variant UoM overrides (для прокату вага variant'а різна), прокат-specific forms (steel-mark selector, ГОСТ-номер lookup), інтеграція з ShipCore cargo_handling domain.
  • Western ERP ref: SAP Variant Configuration з industry-specific add-ons (Steel/Chemical/Pharma), Microsoft Dynamics Industry Solutions — convergent pattern «universal core + vertical adapters».
  • Деталі: залежить від внутрішнього prerequisite — ShipCore Phase 6 (rail/road) повинен принести concrete cargo_handling domain. Зараз domain поки шкаралупа. До тих пір — premature.

[ESWF] Dashboard S4c — Personal Launchpad customisation (Variant C) ⏸️ 👤

  • Арх.бенефіт: завершує Dashboard Framework S4 vision (drag-drop кастомізація Home). S1-S4b shipped 2026-05-09, S5-mini shipped 2026-05-22. S4c = remaining gap до feature-complete Personal Launchpad.
  • Western ERP ref: SAP Fiori Launchpad Edit Mode / NetSuite Dashboard Personalize / Dynamics Saved Views / Salesforce Home Page Layouts — convergent pattern «role presets + per-user override».
  • Деталі (shape session output needed): drag-drop через @dnd-kit/core, "Pin to home" з кожного section dashboard, persistence в UserPreferences.dashboard_layout: jsonb, role-presets (Sales Manager / Accountant / Warehouse Operator / CEO). Shape questions: touch-friendly drag на mobile? UX of "reset to role default"? Persistence on every move vs explicit Save? Що з shared layouts (team-wide presets)? Без shape — over-engineering. ~2-3 тижні implementation після shape.

🌐 Application Federation Protocol (AFP) track — deferred Phase 4-7

Concept session 2026-05-17 закрито. Повна архітектура у planning/application-federation-protocol-2026-05-17.md: 7 фаз, 10 ADR. Phase 1-3 — у P1 черзі вище. Phase 4-7 deferred з legitimate non-client тригерами.

  • [ ] AFP Phase 4 Shop↔T1 — реактивація коли архітектурно знадобиться separation frontend/shop у окремий tenant від T1. Зараз shop живе в тому ж tenant — sync не потрібна.
  • [ ] AFP Phase 5 UA/MD→DE cross-server consolidation — реактивація коли DE-сервер фізично доступний (real external dependency).
  • [ ] AFP Phase 6 MDM AI matching — реактивація коли обсяг unmapped entries у Group MDM перевищить ~1000 (data-driven тригер на основі Phase 3 metrics).
  • [ ] AFP Phase 7 Drill-down UI на DE — архітектурно після Phase 5.

🚢 ShipCore implementation track

ShipCore concept session закрито 2026-05-12 (21 файл / ~85K слів / 25 ADR у dop/modules/vertical/shipcore/). Phase 4 backend renames + Phase 5 shipcore_sea backend + R-1..R-5 terminal decomposition + Variants V1-V5 CLOSED 2026-05-21. Phase 7 pricing concept + Phase 5 Day-9+ frontend shape — у P1 черзі вище.

Phase 5 ShipCore Sea — deferred deliverables (external/internal blockers)

  • [ ] ⏸️ Phase 5 Day-7 — MaerskSpotAdapter real internals — DEFERRED, external dependency. Maersk Developer Portal sandbox credentials (~2 days self-service signup + customer-agreement step для production keys). Bait готовий: scaffold у c815044, NotConfigured guard працює, 5 Protocol-методів raise NotImplementedError. Реактивація: Maersk creds у руках. Імплементація автономна після цього (DCSA Booking 2.0 + T&T 2.2 + VGM 1.0 + BL 3.0 mapping вже типізовано через 3 згенеровані pydantic families).
  • [ ] ⏸️ Phase 5 — TNT codegen — DEFERRED, internal small autonomous fix. TNT_v2.2.0.yaml має external $ref URLs у dcsaorg/DCSA-domain, datamodel-code-generator ламається. Workaround: swagger-cli bundle перед regen. ~30 хв. Беремо коли потрібно T&T-events ingestion (real-time tracking).
  • [ ] ⏸️ Phase 5 — VGM codegen — DEFERRED, external mini-step. DCSA VGM 1.0 опубліковано Nov 2025 але YAML лише на SwaggerHub. Manual SwaggerHub → Export → Download API → YAML Resolved once, drop у yaml/vgm_1.0.yaml. До того часу MaerskSpotAdapter.submit_vgm працює з hand-crafted dict (~10 полів).

Terminal decomposition — R-4.1 cleanup

  • [ ] 🤖 R-4.1 — containerhubSection preset-shell cleanup (поставлено 2026-05-22). R-4 реформував лише applications.ts metadata; frontend/dop/containerhub/config.ts (~1005 LoC) ще містить full legacy-set items, що тепер живуть у composing sections. 12 дубльованих items: containers/containerInspections/containerSeals/containerTypes/shippingLines/containerTariffs (vs shipcoreContainersSection); gateTransactions/gatePhotos/yardInventories/yardInventoryLines/droneResults/storageChargeLedger (vs shipcoreCargoOpsSection); containerBookings/containerMovements/demurrageCalculations/containerLedger (vs shipcoreContainersSection). Унікальне залишити: terminals+zones, yard processes (yardMap/stackingOptimizer/gateControl/inventoryDashboard/demurrageTracker), integration hub (integrations/messages), analytics (5 звітів). Acceptance: containerhubSection lean preset-shell ~200-300 LoC (замість 1005), кожен sidebar item має одне місце правди.

External blockers (factual — non-client triggers)

  • [ ] [SHC] Maersk Spot sandbox credentials — outreach + onboarding ~1-2 тижні. Потрібно для Phase 5 deliverable. Sandbox self-service, production вимагає customer agreement.
  • [ ] [SHC] УЗ Cargo / ГІОЦ B2B-договір + NDA — onboarding 2-6 тижнів per shipcore/phase2-ua-integrations.md. Потрібно для Phase 6 shipcore_rail integration через АС Клієнт УЗ + е.Портал.
  • [ ] [SHC] Awery outreach (Tristan Koch CCO) — Phase 9+ avia partnership (Model C bidirectional ONE Record). Можна стартувати у Phase 4-5 calendar window паралельно з основним impl track.
  • [ ] [SHC] Pilot Wave 1 UA road carrier — identify + agreement — outreach через AsMAP membership list / LinkedIn long-list. Узгодити з менеджментом обраного pilot per shipcore/phase1-ua-customers.md § Profile 2. Pilot outreach policy (memory pilot_outreach_policy): не починаємо до коли product не demo-grade.

Календарні deadlines (regulatory — non-client triggers)

  • ❌ 2026-06-01 — ICS2 Release 3 mandatory для PL/RO/SK/HR/LV — пропускаємо свідомо (v1 = UA-only per decisions § C7)
  • ✅ 2027-01-01 — eTTN UA mandatory — Phase 4 deliverable, must hit (2 backends Vchasno + M.E.Doc)
  • ⚠️ 2027-07-09 — eFTI mandatory для public authorities (EU Reg 2020/1056) — Phase 8 deliverable, ризик якщо Phase 4 ковзне >2 months
  • 📅 2030 — DCSA eBL 100% adoption (9 carriers commit) — Phase 8 хаби (CargoX + WaveBL)

🎯 Окремі сесії (стартують за явним запитом користувача)

[ESWF] ESWF skeleton experiment — «порожня кімната» 👤

  • Арх.бенефіт: гіпотеза-перевірка чи ESWF справді framework для швидкої розробки бізнес-додатків, чи маркетингове відмежування. Підхід переглянуто 2026-05-17 з sibling-папки на frontend monorepo split після 4 leak'ів сесії. Несуча конструкція для 4 запланованих ініціатив: module versioning, ShipCore Phase 4 refactor, update delivery (community vs enterprise), AFP Phase 1.
  • Прийнята структура: frontend/core/ + frontend/dop/ (22 модулі) + frontend/blank_demo/ (другий продукт-консумер, sibling до dop/) + portal/+news/+shop/ (окремі веб-сайти). Цільовий читач blueprint — 1С-ник без Python/JS у термінах довідник/документ/реквізит/табчастина.
  • План фаз A-D + 4 виявлені leak'и + 5 рішень по осях — planning/skeleton-experiment-2026-05-17.md. Backend (backend/dop/ симетрія?) — окрема сесія, відкладено до завершення frontend Phase A-C. Окрема сесія, не batch.

💡 Ідеї (raw, без пріоритету)

  • AI-агент «Виписати рахунок» — Phase 1 (chat-trigger) ✅ shipped 2026-05-11. Деталі: dop/features/ai-invoice-agent.md. Phase 2 (email-trigger через IMAP+HMAC) — у backlog, deferred до спільної інфри з Agent Inbox.
  • Agent Inbox — автономна розробка через AI-агента — лист клієнта з багом/фічею → AI-агент тріажить → Draft PR на worktree → Dev preview → approval власника → prod deploy. Реактивація: (а) період недоступності власника (army — real external constraint), або (б) природне продовження core/federation Phase 1 — коли outbox/inbox primitive дасть baseline, Agent Inbox стає архітектурним extension цього паттерну.