„Připojeno" odvozené z existence dat — a CONNECTED stub bez funkčního adaptéru
import { Aside } from ‘@astrojs/starlight/components’;
Symptom
Sekce “Symptom”Copilot ukazuje „připojte e-mail” firmě s právě připojenou (zatím prázdnou) schránkou — a naopak „banka připojena” firmě bez banky, která má jen importovanou fakturu. Po opravě první poloviny se objevila druhá: ručně nastavený záznam status=CONNECTED (admin PATCH, jednorázový onboarding scan se syncEnabled=false) vytvořil capability, přestože synchronizační endpoint pro všechny konektory vrací 501.
Root cause
Sekce “Root cause”- Osa připojení zaměněná za aktivitu: „configured” se počítal z existence dat (
∃ e-mail,∃ účetní položka se source ≠ MANUAL). Existence dat je AKTIVITA; jako důkaz PŘIPOJENÍ lže oběma směry — prázdný připojený zdroj vypadá nepřipojeně, data z cizího typu zdroje (import faktur) vypadají jako připojená banka. - Status štítek není důkaz funkčnosti:
Integration.status=CONNECTEDuměly zapsat tři cesty bez funkčního adaptéru (admin PATCH bez ověření, jednorázový scan bez uchování credentials, ruční stub) — a derivace ho brala jako pravdu.
Fix
Sekce “Fix”- Nová strukturální derivace oddělená od aktivitního semaforu (semafor zůstal pro své povrchy beze změny).
- Připojení = existence dat TÉHOŽ typu ∨ konfigurační artefakt zdroje (setting) ∨ registrovaný funkční adaptér (
provider ∈ registr ∧ CONNECTED ∧ syncEnabled=true). - Registr funkčních adaptérů je prázdná konstanta — dokud reálný persistentní sync neexistuje, status větev se vůbec nedotazuje. Zápis providera = závazek s vlastním review („může admin vyrobit falešný řádek tohoto providera?”).
Poučení
Sekce “Poučení”Trust vrstva (capability → „připojte X” CTA) musí stát na strukturální pravdě, ne na štítcích ani na vedlejších datech. Každý zdroj „pravdy o připojení” prověř otázkou: kdo všechno tuhle hodnotu umí zapsat a co přesně dokazuje?